Re: Review Request 58813: GEODE-2776 After region is updated with loader, the ClientEvent is set with current entry version tag

[anilkumar gingade]

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

(Updated May 5, 2017, 3:57 a.m.)


Review request for geode, Darrel Schneider, Eric Shu, and Lynn Gallinat.


Changes
---

Fixing unit test failure ProxyJUnitTest.testExpiration()


Repository: geode


Description
---

When client does a get() which results in adding an entry by calling loader on 
server side, the client event returned back is not updated with the version tag 
that is created with the new entry on server. This results in client having a 
different version tag than the server side entry. If client has registered 
event, and is concurrently updating the entry (from get() call and an 
register-event from server), it could result in data consistency between client 
and server.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
0c967c9 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
2dec53b 
  
geode-core/src/test/java/org/apache/geode/internal/cache/DistributedRegionSearchLoadJUnitTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/58813/diff/5/

Changes: https://reviews.apache.org/r/58813/diff/4-5/


Testing
---

Manual testing.
Running new unit test (added) with and without changes.
precheckin in progress.


Thanks,

anilkumar gingade

[jira] [Resolved] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()

[nabarun (JIRA)]

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

nabarun resolved GEODE-2879.

   Resolution: Fixed
Fix Version/s: 1.2.0

> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



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

[jira] [Commented] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2879:


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

GEODE-2879: LonerDistributionManager shutdown called from close

* LonerDistributionManager shutdown was not being called from close() 
method call.
* This resulted in the thread pool's threads to wait for 1 minute of 
inactivity for them to be killed.
* This resulted in an extra delay while test executions.
* shutdown called from close method


> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



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

Re: [gemfire-dev] New Client-Server Protocol Proposal

[William Markito Oliveira]

+1 for that as well
On Thu, May 4, 2017 at 5:21 PM Dan Smith  wrote:

> >
> > I wouldn't tackle that at this layer. I would suggest adding a layer
> > between the message and TCP that creates channels that are opaque to the
> > message layer above. The message layer wouldn't know if it was talking to
> > multiple sockets to the client or single socket with multiple channels.
> >
>
> ++1 on that!
>

[jira] [Assigned] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()

[nabarun (JIRA)]

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

nabarun reassigned GEODE-2879:
--

Assignee: nabarun

> LonerDistributionManager's Shutdown not being called in close()
> ---
>
> Key: GEODE-2879
> URL: https://issues.apache.org/jira/browse/GEODE-2879
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: nabarun
>Assignee: nabarun
>
> Issue:
> LonerDistributionManager shutdown was not being called from close() method 
> call.
> This resulted in the thread pool's threads to wait for 1 minute of inactivity 
> for them to be killed.
> This resulted in an extra delay while test executions.
> Solution:
> Call shutdown from close()



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

Re: Review Request 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache

[Kirk Lund]

> On May 4, 2017, 11:08 p.m., Ken Howe wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java
> > Line 8918 (original), 8603 (patched)
> > 
> >
> > Was this intended to be 'ForceReattemptException ignore'?

Looks like it used to be ignor but I changed to e because the caught exception 
is used in the debug statement.


- Kirk


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


On May 3, 2017, 10:10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 3, 2017, 10:10 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
> Howe, and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache
> 
> * misc cleanup of code where possible
> 
> I'm running full regression and precheckin. Sorry this is so many files -- 
> I'm not sure this is even practical to review :/
> 
> I'd like to avoid any further cleanup and just get this committed asap to 
> avoid conflicts. Let's hold off on throwing more changes on top of this if 
> you see more lines of code in a file that you'd like cleaned up. I obviously 
> want to fix problems in any code that I touched though!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCALocalTransaction.java
>  112f2fa44478f00782bcb717d8cb75233c979dce 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCAManagedConnection.java
>  520f7e245ca3493d54ac661da29f58a3dfc71189 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 58518f4f5d43b3fe214a1218703360928efdee52 
>   geode-core/src/main/java/org/apache/geode/admin/GemFireMemberStatus.java 
> 5b4e59ef341007a4e42cd5a10b4e8a2eb4d18deb 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/CacheHealthEvaluator.java
>  f7ff9ede1e074425ce7aa7bed1a63c72c5174bf6 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FinishBackupRequest.java
>  25abd7ee5d346d764d68339ae6c03b2cffc63bc8 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FlushToDiskRequest.java
>  ff6dd9d2088124203842a06d3a794e00a5636246 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/MemberHealthEvaluator.java
>  951b364718f43c5efc85c0f0f0e5d54e24d87ced 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/PrepareBackupRequest.java
>  7025721180cb6b158cff4b21bfcea6549780ccd3 
>   geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java 
> 1a46f241a7b3a4bbbd47da70c227b3e3ea237fd0 
>   geode-core/src/main/java/org/apache/geode/cache/CacheClosedException.java 
> b24bc2fc5ad39737e908f9df2704b62728222629 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 0772dcf86b3d3ea9eebfe1d324c8fa043fa8ac79 
>   geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
> 57a1a465c1bd0d91d8bb83ad2b97db1f2efbb025 
>   geode-core/src/main/java/org/apache/geode/cache/GemFireCache.java 
> e60bc59a88051ac11a863ea10be3e2bf07e4cbe7 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 
> 3eef5438e78a94acd669764e88daaafe6f5fa388 
>   geode-core/src/main/java/org/apache/geode/cache/RegionFactory.java 
> 3a2e9f68c96f9e4aae5a837e175014a3598f69ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/TransactionDataRebalancedException.java
>  fded49f3c00772f38bac14bc57fa4614144930c1 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  1a4052b27688c8e04addf6987ce39ea006f71cc5 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  0def5d283e359b1766fc90dfa05903526c672b0b 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  e799880d715ed1fba65df305cf37e92f27db54ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/SerialAsyncEventQueueImpl.java
>  9252dc745b848ea7a5aa8793a1fdb3a3c004c7ee 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  e72cbff048b5a7ecb24594382d776feaa8e0f4bd 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
>  ef676673046c32f68558f85516c674f7dcc6e982 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
>  a494138316d8538f3aebeffb7075bb2db33b6532 
>   
> 

[jira] [Created] (GEODE-2879) LonerDistributionManager's Shutdown not being called in close()

[nabarun (JIRA)]

nabarun created GEODE-2879:
--

 Summary: LonerDistributionManager's Shutdown not being called in 
close()
 Key: GEODE-2879
 URL: https://issues.apache.org/jira/browse/GEODE-2879
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: nabarun


Issue:
LonerDistributionManager shutdown was not being called from close() method call.
This resulted in the thread pool's threads to wait for 1 minute of inactivity 
for them to be killed.
This resulted in an extra delay while test executions.

Solution:
Call shutdown from close()



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

Re: GEODE-2708: Upgrading Gradle Wrapper to 3.4.1

[Mark Bretl]

This is now checked in on Develop.

Happy Building!

--Mark

On Tue, May 2, 2017 at 11:46 AM, Udo Kohlmeyer 
wrote:

> +1, so have I
>
>
>
> On 5/2/17 11:09, Jared Stewart wrote:
>
>> +1 I've been running with Gradle 3+ without issues too
>>
>> On May 2, 2017, at 11:04 AM, Anthony Baker  wrote:
>>>
>>> +1 I’ve been running against gradle 3+ for awhile now.
>>>
>>> Anthony
>>>
>>> On May 2, 2017, at 10:55 AM, Mark Bretl  wrote:

 I have done testing to upgrade our current Gradle wrapper version from
 2.14.1 to 3.4.1. There are a couple of warnings during the build,
 however,
 I didn't see anything in a precheckin run that would be an issue.

 Anybody have any issues with updating Gradle before releasing 1.2.0?

 If there no objections, I will checkin the upgrade changes on Thursday
 EOD
 PST.

 --Mark

>>>
>

[jira] [Assigned] (GEODE-2708) Update Gradle Wrapper to Gradle 3

[Mark Bretl (JIRA)]

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

Mark Bretl reassigned GEODE-2708:
-

Assignee: Mark Bretl

> Update Gradle Wrapper to Gradle 3
> -
>
> Key: GEODE-2708
> URL: https://issues.apache.org/jira/browse/GEODE-2708
> Project: Geode
>  Issue Type: Task
>  Components: build
>Reporter: Galen O'Sullivan
>Assignee: Mark Bretl
> Fix For: 1.2.0
>
>
> It looks like we're still running on a very old version of Gradle. This may 
> be related to incremental builds not working properly.
> {code}
> $ ./gradlew --version
> 
> Gradle 2.14.1
> 
> Build time:   2016-07-18 06:38:37 UTC
> Revision: d9e2113d9fb05a5caabba61798bdb8dfdca83719
> Groovy:   2.4.4
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> $ gradle --version
> 
> Gradle 3.4.1
> 
> Build time:   2017-03-03 19:45:41 UTC
> Revision: 9eb76efdd3d034dc506c719dac2955efb5ff9a93
> Groovy:   2.4.7
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> {code}



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

[jira] [Resolved] (GEODE-2708) Update Gradle Wrapper to Gradle 3

[Mark Bretl (JIRA)]

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

Mark Bretl resolved GEODE-2708.
---
   Resolution: Fixed
Fix Version/s: 1.2.0

Gradle Wrapper now updated to 3.4.1

> Update Gradle Wrapper to Gradle 3
> -
>
> Key: GEODE-2708
> URL: https://issues.apache.org/jira/browse/GEODE-2708
> Project: Geode
>  Issue Type: Task
>  Components: build
>Reporter: Galen O'Sullivan
>Assignee: Mark Bretl
> Fix For: 1.2.0
>
>
> It looks like we're still running on a very old version of Gradle. This may 
> be related to incremental builds not working properly.
> {code}
> $ ./gradlew --version
> 
> Gradle 2.14.1
> 
> Build time:   2016-07-18 06:38:37 UTC
> Revision: d9e2113d9fb05a5caabba61798bdb8dfdca83719
> Groovy:   2.4.4
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> $ gradle --version
> 
> Gradle 3.4.1
> 
> Build time:   2017-03-03 19:45:41 UTC
> Revision: 9eb76efdd3d034dc506c719dac2955efb5ff9a93
> Groovy:   2.4.7
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> {code}



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

[jira] [Created] (GEODE-2878) If an exception occurs after retrieving an XAConnection from the ConnectionProvider but before returning it to the application, the GemFireTransactionDataSource doesn't r

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-2878:


 Summary: If an exception occurs after retrieving an XAConnection 
from the ConnectionProvider but before returning it to the application, the 
GemFireTransactionDataSource doesn't return it to the pool
 Key: GEODE-2878
 URL: https://issues.apache.org/jira/browse/GEODE-2878
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Barry Oglesby


In my test, I have 5 threads inserting rows into a derby database.

At first, as connections are being used and returned, the {{activeConnections}} 
is updated correctly:
{noformat}
Thread-16: AbstractPoolCache.getPooledConnectionFromPool activeConnections=1
Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=2
Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=3
Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=4
Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=5
Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=4
Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=3
Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=2
Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=1
Thread-15: AbstractPoolCache.returnPooledConnectionToPool activeConnections=0
{noformat}
But, then if an exception occurs after retrieving the {{XAConnection}}, it is 
not return to the {{ConnectionProvider}}.

In my test, the exception occurs in 
{{GemFireTransactionDataSource.registerTranxConnection}}:
{noformat}
java.lang.Exception: GemFireTransactionDataSource-registerTranxConnection(). 
Exception in registering the XAResource with the Transaction.Exception 
occurred= javax.transaction.SystemException: 
GlobalTransaction::enlistResource::error while enlisting XAResource 
org.apache.derby.client.am.XaException: XAER_RMFAIL : An error occurred during 
a deferred connect reset and the connection has been terminated.
at 
org.apache.geode.internal.datasource.GemFireTransactionDataSource.registerTranxConnection(GemFireTransactionDataSource.java:218)
at 
org.apache.geode.internal.datasource.GemFireTransactionDataSource.getConnection(GemFireTransactionDataSource.java:127)
at TestServer.saveToDB(TestServer.java:177)
at TestServer.save(TestServer.java:154)
at TestServer.loadEntriesIntoDerby(TestServer.java:127)
at TestServer$1.run(TestServer.java:112)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This is after the {{XAConnection}} has been retrieved from the 
{{ConnectionProvider}} and the {{activeConnections}} incremented, but before it 
has been returned to the application. Neither the {{registerTranxConnection}} 
method nor its caller ({{getConnection}}) does anything other than to throw the 
exception. The {{XAConnection}} is not returned to the pool nor is the 
{{activeConnections}} decremented.

Finally, if enough of these exceptions occur, the test stops because all 30 
(default max) connections are in use. They aren't really in use, its just that 
the activeConnections counter hasn't been properly maintained.
{noformat}
Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
Thread-16: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
Thread-18: AbstractPoolCache.returnPooledConnectionToPool activeConnections=28
Thread-15: AbstractPoolCache.getPooledConnectionFromPool activeConnections=29
Thread-17: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
Thread-14: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
Thread-18: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
Thread-17: AbstractPoolCache.returnPooledConnectionToPool activeConnections=29
Thread-14: AbstractPoolCache.getPooledConnectionFromPool activeConnections=30
{noformat}
It doesn't really matter what the exception is. If one occurs after retrieving 
the {{XAConnection}}, it needs to be returned to the {{ConnectionProvider}} or 
at the very least, the {{activeConnections}} must be decremented.




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

[jira] [Commented] (GEODE-2708) Update Gradle Wrapper to Gradle 3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2708:


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

GEODE-2708: Update Minimum Gradle Version To 3.4.1


> Update Gradle Wrapper to Gradle 3
> -
>
> Key: GEODE-2708
> URL: https://issues.apache.org/jira/browse/GEODE-2708
> Project: Geode
>  Issue Type: Task
>  Components: build
>Reporter: Galen O'Sullivan
>
> It looks like we're still running on a very old version of Gradle. This may 
> be related to incremental builds not working properly.
> {code}
> $ ./gradlew --version
> 
> Gradle 2.14.1
> 
> Build time:   2016-07-18 06:38:37 UTC
> Revision: d9e2113d9fb05a5caabba61798bdb8dfdca83719
> Groovy:   2.4.4
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> $ gradle --version
> 
> Gradle 3.4.1
> 
> Build time:   2017-03-03 19:45:41 UTC
> Revision: 9eb76efdd3d034dc506c719dac2955efb5ff9a93
> Groovy:   2.4.7
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> {code}



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

[jira] [Commented] (GEODE-2708) Update Gradle Wrapper to Gradle 3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2708:


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

GEODE-2708: Update Gradle Wrapper To 3.4.1

Tested and Verified By: ./gradlew precheckin


> Update Gradle Wrapper to Gradle 3
> -
>
> Key: GEODE-2708
> URL: https://issues.apache.org/jira/browse/GEODE-2708
> Project: Geode
>  Issue Type: Task
>  Components: build
>Reporter: Galen O'Sullivan
>
> It looks like we're still running on a very old version of Gradle. This may 
> be related to incremental builds not working properly.
> {code}
> $ ./gradlew --version
> 
> Gradle 2.14.1
> 
> Build time:   2016-07-18 06:38:37 UTC
> Revision: d9e2113d9fb05a5caabba61798bdb8dfdca83719
> Groovy:   2.4.4
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> $ gradle --version
> 
> Gradle 3.4.1
> 
> Build time:   2017-03-03 19:45:41 UTC
> Revision: 9eb76efdd3d034dc506c719dac2955efb5ff9a93
> Groovy:   2.4.7
> Ant:  Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> JVM:  1.8.0_111 (Oracle Corporation 25.111-b14)
> OS:   Mac OS X 10.12.3 x86_64
> {code}



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

Re: Review Request 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java
Line 6768 (original), 6589 (patched)


typo: 2nd '{@code' should be '}'



geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java
Line 8918 (original), 8603 (patched)


Was this intended to be 'ForceReattemptException ignore'?


- Ken Howe


On May 3, 2017, 10:10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 3, 2017, 10:10 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
> Howe, and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache
> 
> * misc cleanup of code where possible
> 
> I'm running full regression and precheckin. Sorry this is so many files -- 
> I'm not sure this is even practical to review :/
> 
> I'd like to avoid any further cleanup and just get this committed asap to 
> avoid conflicts. Let's hold off on throwing more changes on top of this if 
> you see more lines of code in a file that you'd like cleaned up. I obviously 
> want to fix problems in any code that I touched though!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCALocalTransaction.java
>  112f2fa44478f00782bcb717d8cb75233c979dce 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCAManagedConnection.java
>  520f7e245ca3493d54ac661da29f58a3dfc71189 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 58518f4f5d43b3fe214a1218703360928efdee52 
>   geode-core/src/main/java/org/apache/geode/admin/GemFireMemberStatus.java 
> 5b4e59ef341007a4e42cd5a10b4e8a2eb4d18deb 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/CacheHealthEvaluator.java
>  f7ff9ede1e074425ce7aa7bed1a63c72c5174bf6 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FinishBackupRequest.java
>  25abd7ee5d346d764d68339ae6c03b2cffc63bc8 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FlushToDiskRequest.java
>  ff6dd9d2088124203842a06d3a794e00a5636246 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/MemberHealthEvaluator.java
>  951b364718f43c5efc85c0f0f0e5d54e24d87ced 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/PrepareBackupRequest.java
>  7025721180cb6b158cff4b21bfcea6549780ccd3 
>   geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java 
> 1a46f241a7b3a4bbbd47da70c227b3e3ea237fd0 
>   geode-core/src/main/java/org/apache/geode/cache/CacheClosedException.java 
> b24bc2fc5ad39737e908f9df2704b62728222629 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 0772dcf86b3d3ea9eebfe1d324c8fa043fa8ac79 
>   geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
> 57a1a465c1bd0d91d8bb83ad2b97db1f2efbb025 
>   geode-core/src/main/java/org/apache/geode/cache/GemFireCache.java 
> e60bc59a88051ac11a863ea10be3e2bf07e4cbe7 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 
> 3eef5438e78a94acd669764e88daaafe6f5fa388 
>   geode-core/src/main/java/org/apache/geode/cache/RegionFactory.java 
> 3a2e9f68c96f9e4aae5a837e175014a3598f69ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/TransactionDataRebalancedException.java
>  fded49f3c00772f38bac14bc57fa4614144930c1 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  1a4052b27688c8e04addf6987ce39ea006f71cc5 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  0def5d283e359b1766fc90dfa05903526c672b0b 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  e799880d715ed1fba65df305cf37e92f27db54ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/SerialAsyncEventQueueImpl.java
>  9252dc745b848ea7a5aa8793a1fdb3a3c004c7ee 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  e72cbff048b5a7ecb24594382d776feaa8e0f4bd 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
>  ef676673046c32f68558f85516c674f7dcc6e982 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
>  a494138316d8538f3aebeffb7075bb2db33b6532 
>   
> 

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Dan Smith]

>
> I wouldn't tackle that at this layer. I would suggest adding a layer
> between the message and TCP that creates channels that are opaque to the
> message layer above. The message layer wouldn't know if it was talking to
> multiple sockets to the client or single socket with multiple channels.
>

++1 on that!

Re: Review Request 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java
Line 672 (original), 676 (patched)


Remove the "{@code" and the closing "}" to get the snippet formatted 
resaonably in hte javadoc



geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java
Line 2001 (original), 1960-1961 (patched)


Swap these lines to keep the comments contiguous


- Ken Howe


On May 3, 2017, 10:10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 3, 2017, 10:10 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
> Howe, and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache
> 
> * misc cleanup of code where possible
> 
> I'm running full regression and precheckin. Sorry this is so many files -- 
> I'm not sure this is even practical to review :/
> 
> I'd like to avoid any further cleanup and just get this committed asap to 
> avoid conflicts. Let's hold off on throwing more changes on top of this if 
> you see more lines of code in a file that you'd like cleaned up. I obviously 
> want to fix problems in any code that I touched though!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCALocalTransaction.java
>  112f2fa44478f00782bcb717d8cb75233c979dce 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCAManagedConnection.java
>  520f7e245ca3493d54ac661da29f58a3dfc71189 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 58518f4f5d43b3fe214a1218703360928efdee52 
>   geode-core/src/main/java/org/apache/geode/admin/GemFireMemberStatus.java 
> 5b4e59ef341007a4e42cd5a10b4e8a2eb4d18deb 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/CacheHealthEvaluator.java
>  f7ff9ede1e074425ce7aa7bed1a63c72c5174bf6 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FinishBackupRequest.java
>  25abd7ee5d346d764d68339ae6c03b2cffc63bc8 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FlushToDiskRequest.java
>  ff6dd9d2088124203842a06d3a794e00a5636246 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/MemberHealthEvaluator.java
>  951b364718f43c5efc85c0f0f0e5d54e24d87ced 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/PrepareBackupRequest.java
>  7025721180cb6b158cff4b21bfcea6549780ccd3 
>   geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java 
> 1a46f241a7b3a4bbbd47da70c227b3e3ea237fd0 
>   geode-core/src/main/java/org/apache/geode/cache/CacheClosedException.java 
> b24bc2fc5ad39737e908f9df2704b62728222629 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 0772dcf86b3d3ea9eebfe1d324c8fa043fa8ac79 
>   geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
> 57a1a465c1bd0d91d8bb83ad2b97db1f2efbb025 
>   geode-core/src/main/java/org/apache/geode/cache/GemFireCache.java 
> e60bc59a88051ac11a863ea10be3e2bf07e4cbe7 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 
> 3eef5438e78a94acd669764e88daaafe6f5fa388 
>   geode-core/src/main/java/org/apache/geode/cache/RegionFactory.java 
> 3a2e9f68c96f9e4aae5a837e175014a3598f69ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/TransactionDataRebalancedException.java
>  fded49f3c00772f38bac14bc57fa4614144930c1 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  1a4052b27688c8e04addf6987ce39ea006f71cc5 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  0def5d283e359b1766fc90dfa05903526c672b0b 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  e799880d715ed1fba65df305cf37e92f27db54ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/SerialAsyncEventQueueImpl.java
>  9252dc745b848ea7a5aa8793a1fdb3a3c004c7ee 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  e72cbff048b5a7ecb24594382d776feaa8e0f4bd 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
>  ef676673046c32f68558f85516c674f7dcc6e982 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
>  

[jira] [Resolved] (GEODE-2870) BucketMovedException during function execution may lead to client missing results

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2870.

   Resolution: Fixed
Fix Version/s: 1.2.0

> BucketMovedException during function execution may lead to client missing 
> results
> -
>
> Key: GEODE-2870
> URL: https://issues.apache.org/jira/browse/GEODE-2870
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> If a function isHA and hasResult, if checkForBucketMovement() throws the 
> BucketMovedException, this escapes the synchronized lastResult() method.  
> Propogating this to through the user function.  
> Hopefully the user function does something appropriate or allows it to 
> propagate to AbstractExecution.executeFunctionLocally(), which hands it to 
> handleException.  Here is where the exception is written back to the client.
> However, because we have now escaped the synchronized method, the thread can 
> be paused.  
> A remote execution returns with results and now enters the synchronized 
> lastResult() method.  The state flags have been set and now this result is 
> considered the last result and lastResult is now sent.  We end up not 
> retrying even though the local node had failed.  It just hadn't had the 
> opportunity to send the exception back.
> This issue has probably been in the product for a long time.



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

Re: Geode Native Release

[John Blum]

Jacob - Ah, sorry to hear that.

On Thu, May 4, 2017 at 2:09 PM, Jacob Barrett  wrote:

> John, I wish we could do that but Apache would require that geode-native be
> a fully qualified sub-project with all the headache that goes with that to
> "release" separately.
>
>
> On Thu, May 4, 2017 at 11:35 AM John Blum  wrote:
>
> > A good reason to use separate repos.  Individual components of Geode,
> > especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc,
> > should be separately and independently releasable to provide a smoother
> > release cadence based on velocity and community need.
> >
> > Then, using a Maven "BOM", you can tie all the independent (yet
> compatible)
> > versions together in 1 cohesive collection of artifacts for a particular
> > release of Geode.
> >
> > You think all the SD modules in the "release train" have a same version?
> > No!
> >
> > Case in point...
> >
> >
> > https://github.com/spring-projects/spring-data-build/
> blob/1.9.3.RELEASE/bom/pom.xml#L21-L146
> >
> > They all have the same "symbolic" version though...
> >
> >
> > https://github.com/spring-projects/spring-data-build/
> blob/1.9.3.RELEASE/bom/pom.xml#L6-L7
> >
> > Which is what other projects (e.g. *Spring Boot*) use to pull in the SD
> > train...
> >
> >
> > https://github.com/spring-projects/spring-boot/blob/v1.
> 5.3.RELEASE/spring-boot-dependencies/pom.xml#L158
> >
> >
> > https://github.com/spring-projects/spring-boot/blob/v1.
> 5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094
> >
> > While we don't typically release individual SD modules (though, it has
> been
> > known to occur [1]), we could.  But, we try to keep all modules in sync
> > with the train since all have a common core (*Spring Framework* / *Spring
> > Data Commons*), but they have all different versions.  Many other open
> > source projects operate the same way... Reactor.
> >
> > $0.02
> >
> > -John
> >
> >
> > [1]
> >
> > https://github.com/spring-projects/spring-data-gemfire/
> tree/1.8.4.RELEASE-PATCH01
> >
> >
> > On Thu, May 4, 2017 at 11:23 AM, Anthony Baker 
> wrote:
> >
> > > Let’s say we release geode-native along with geode 1.2.  When it comes
> > > time to release 1.3 (and geode-native is not yet ready) we would be
> > > creating release branches from:
> > >
> > > geode:  develop
> > > geode-example:  develop
> > > geode-native:   release/v1.2.0
> > >
> > > Anthony
> > >
> > > > On May 4, 2017, at 11:16 AM, Jacob Barrett 
> > wrote:
> > > >
> > > > I don't see how they are different branches? If geode-Native has
> > > release/1.2 and Geode has release/1.2?
> > > >
> > > > Sent from my iPhone
> > > >
> > > >> On May 4, 2017, at 10:21 AM, Anthony Baker 
> wrote:
> > > >>
> > > >> I think it’s confusing to cut a release from different branches for
> > > geode, geode-examples, and geode-native but I don’t have a better idea.
> > > >>
> > > >> +0
> > > >>
> > > >> Anthony
> > > >>
> > > >>> On May 4, 2017, at 7:29 AM, Jacob Barrett 
> > wrote:
> > > >>>
> > > >>> All,
> > > >>>
> > > >>> I want to start the discussion on releasing Geode Native C++ and
> .NET
> > > >>> clients with the next or near future Geode release.
> > > >>>
> > > >>> There are a few house keeping items left in the source release JIRA
> > > [1]. It
> > > >>> would be great to get some help completing these tasks.
> > > >>>
> > > >>> If we start with a source only release, which Geode release should
> we
> > > >>> target? Since it is "adding feature" it seems it makes the most
> sense
> > > to do
> > > >>> it as part of a minor release, say 1.2.
> > > >>>
> > > >>> To throw a little wrench in it all. There are some serious changes
> > > coming
> > > >>> with [2] conversion to std::shared_ptr, [3] removal of all globals,
> > [4]
> > > >>> replacing all non-standard concurrency methods. These changes won't
> > be
> > > >>> compatible with sources written against previous releases of
> > > geode-native,
> > > >>> thus suggesting they will need a major rev shortly. My suggestion
> > > would be
> > > >>> to cut a release branch now on geode-native for 1.2 and get it
> ready
> > > for
> > > >>> source release. Backport any changes on the release branch to
> > develop.
> > > That
> > > >>> leaves develop open for marching forward with what would be a 2.0
> set
> > > of
> > > >>> sources. Any release of Geode 1.x would just include the
> geode-native
> > > >>> release/1.x branches until Geode 2.0.
> > > >>>
> > > >>> Thoughts and feedback?
> > > >>>
> > > >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> > > >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> > > >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> > > >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> > > >>>
> > > >>> -Jake
> > > >>
> > >
> > >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>



-- 
-John

Re: Geode Native Release

[Jacob Barrett]

It's the problem we are going to have with two distinctly different modules
sharing the same project release cycle. The best we could do is branch
release/v1.3 form the support/v1.2 branch until we are ready to release the
breaking changes in the geode-native/develop branch.

-Jake


On Thu, May 4, 2017 at 11:23 AM Anthony Baker  wrote:

> Let’s say we release geode-native along with geode 1.2.  When it comes
> time to release 1.3 (and geode-native is not yet ready) we would be
> creating release branches from:
>
> geode:  develop
> geode-example:  develop
> geode-native:   release/v1.2.0
>
> Anthony
>
> > On May 4, 2017, at 11:16 AM, Jacob Barrett  wrote:
> >
> > I don't see how they are different branches? If geode-Native has
> release/1.2 and Geode has release/1.2?
> >
> > Sent from my iPhone
> >
> >> On May 4, 2017, at 10:21 AM, Anthony Baker  wrote:
> >>
> >> I think it’s confusing to cut a release from different branches for
> geode, geode-examples, and geode-native but I don’t have a better idea.
> >>
> >> +0
> >>
> >> Anthony
> >>
> >>> On May 4, 2017, at 7:29 AM, Jacob Barrett  wrote:
> >>>
> >>> All,
> >>>
> >>> I want to start the discussion on releasing Geode Native C++ and .NET
> >>> clients with the next or near future Geode release.
> >>>
> >>> There are a few house keeping items left in the source release JIRA
> [1]. It
> >>> would be great to get some help completing these tasks.
> >>>
> >>> If we start with a source only release, which Geode release should we
> >>> target? Since it is "adding feature" it seems it makes the most sense
> to do
> >>> it as part of a minor release, say 1.2.
> >>>
> >>> To throw a little wrench in it all. There are some serious changes
> coming
> >>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
> >>> replacing all non-standard concurrency methods. These changes won't be
> >>> compatible with sources written against previous releases of
> geode-native,
> >>> thus suggesting they will need a major rev shortly. My suggestion
> would be
> >>> to cut a release branch now on geode-native for 1.2 and get it ready
> for
> >>> source release. Backport any changes on the release branch to develop.
> That
> >>> leaves develop open for marching forward with what would be a 2.0 set
> of
> >>> sources. Any release of Geode 1.x would just include the geode-native
> >>> release/1.x branches until Geode 2.0.
> >>>
> >>> Thoughts and feedback?
> >>>
> >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> >>>
> >>> -Jake
> >>
>
>

Re: Geode Native Release

[Jacob Barrett]

John, I wish we could do that but Apache would require that geode-native be
a fully qualified sub-project with all the headache that goes with that to
"release" separately.


On Thu, May 4, 2017 at 11:35 AM John Blum  wrote:

> A good reason to use separate repos.  Individual components of Geode,
> especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc,
> should be separately and independently releasable to provide a smoother
> release cadence based on velocity and community need.
>
> Then, using a Maven "BOM", you can tie all the independent (yet compatible)
> versions together in 1 cohesive collection of artifacts for a particular
> release of Geode.
>
> You think all the SD modules in the "release train" have a same version?
> No!
>
> Case in point...
>
>
> https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L21-L146
>
> They all have the same "symbolic" version though...
>
>
> https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L6-L7
>
> Which is what other projects (e.g. *Spring Boot*) use to pull in the SD
> train...
>
>
> https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L158
>
>
> https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094
>
> While we don't typically release individual SD modules (though, it has been
> known to occur [1]), we could.  But, we try to keep all modules in sync
> with the train since all have a common core (*Spring Framework* / *Spring
> Data Commons*), but they have all different versions.  Many other open
> source projects operate the same way... Reactor.
>
> $0.02
>
> -John
>
>
> [1]
>
> https://github.com/spring-projects/spring-data-gemfire/tree/1.8.4.RELEASE-PATCH01
>
>
> On Thu, May 4, 2017 at 11:23 AM, Anthony Baker  wrote:
>
> > Let’s say we release geode-native along with geode 1.2.  When it comes
> > time to release 1.3 (and geode-native is not yet ready) we would be
> > creating release branches from:
> >
> > geode:  develop
> > geode-example:  develop
> > geode-native:   release/v1.2.0
> >
> > Anthony
> >
> > > On May 4, 2017, at 11:16 AM, Jacob Barrett 
> wrote:
> > >
> > > I don't see how they are different branches? If geode-Native has
> > release/1.2 and Geode has release/1.2?
> > >
> > > Sent from my iPhone
> > >
> > >> On May 4, 2017, at 10:21 AM, Anthony Baker  wrote:
> > >>
> > >> I think it’s confusing to cut a release from different branches for
> > geode, geode-examples, and geode-native but I don’t have a better idea.
> > >>
> > >> +0
> > >>
> > >> Anthony
> > >>
> > >>> On May 4, 2017, at 7:29 AM, Jacob Barrett 
> wrote:
> > >>>
> > >>> All,
> > >>>
> > >>> I want to start the discussion on releasing Geode Native C++ and .NET
> > >>> clients with the next or near future Geode release.
> > >>>
> > >>> There are a few house keeping items left in the source release JIRA
> > [1]. It
> > >>> would be great to get some help completing these tasks.
> > >>>
> > >>> If we start with a source only release, which Geode release should we
> > >>> target? Since it is "adding feature" it seems it makes the most sense
> > to do
> > >>> it as part of a minor release, say 1.2.
> > >>>
> > >>> To throw a little wrench in it all. There are some serious changes
> > coming
> > >>> with [2] conversion to std::shared_ptr, [3] removal of all globals,
> [4]
> > >>> replacing all non-standard concurrency methods. These changes won't
> be
> > >>> compatible with sources written against previous releases of
> > geode-native,
> > >>> thus suggesting they will need a major rev shortly. My suggestion
> > would be
> > >>> to cut a release branch now on geode-native for 1.2 and get it ready
> > for
> > >>> source release. Backport any changes on the release branch to
> develop.
> > That
> > >>> leaves develop open for marching forward with what would be a 2.0 set
> > of
> > >>> sources. Any release of Geode 1.x would just include the geode-native
> > >>> release/1.x branches until Geode 2.0.
> > >>>
> > >>> Thoughts and feedback?
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> > >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> > >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> > >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> > >>>
> > >>> -Jake
> > >>
> >
> >
>
>
> --
> -John
> john.blum10101 (skype)
>

[jira] [Created] (GEODE-2877) Auth handler: "Cannot pass a GCHandle across AppDomains" in GemStone::GemFire::Cache::IAuthInitialize

[Jacob S. Barrett (JIRA)]

Jacob S. Barrett created GEODE-2877:
---

 Summary: Auth handler: "Cannot pass a GCHandle across AppDomains" 
in GemStone::GemFire::Cache::IAuthInitialize
 Key: GEODE-2877
 URL: https://issues.apache.org/jira/browse/GEODE-2877
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Jacob S. Barrett


If cache authentication module is initialized in AppDomain X and client in 
AppDomain Y tries to authenticate then the callback results in a {{Cannot pass 
a GCHandle across AppDomains}} error.




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

[jira] [Resolved] (GEODE-2852) Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all (local) buckets (not per bucket)

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey resolved GEODE-2852.

   Resolution: Fixed
Fix Version/s: 1.2.0

commit b47673239c9e7dca362de08964326d20a9e1f7bc
Author: Lynn Hughes-Godfrey 
Date:   Thu May 4 11:53:48 2017 -0700

GEODE-2852: Enforce lucene waitUntilFlushed timeout for all buckets

* Since we are now batching waitUntilFlushed threads, do not submit more 
WaitUntilFlushed Callables if timeout exceeded
* create the WaitUntilFlushed Callables just prior to submitting for 
execution so the remaining nanoSeconds can be passed in and applied for each 
bucket.
* updated tests to accommodate changes


> Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all 
> (local) buckets (not per bucket)
> ---
>
> Key: GEODE-2852
> URL: https://issues.apache.org/jira/browse/GEODE-2852
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> Currently, the timeout provided in LuceneServiceImpl.waitUntilFlushed() is 
> applied on a per bucket basis (in each member) within 
> BucketRegionQueue.waitUntilFlushed().
> This timeout needs to be applied across all (local primary) buckets 
> (WaitUntilParallelGatewaySenderFlushedCoordinator).  
> Once the timeout is reached, return false if all WaitUntilFlushed Callables 
> have not been invoked.



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

[jira] [Commented] (GEODE-2852) Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all (local) buckets (not per bucket)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2852:


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

GEODE-2852: Enforce lucene waitUntilFlushed timeout for all buckets

* Since we are now batching waitUntilFlushed threads, do not submit more 
WaitUntilFlushed Callables if timeout exceeded
* create the WaitUntilFlushed Callables just prior to submitting for execution 
so the remaining nanoSeconds can be passed in and applied for each bucket.
* updated tests to accommodate changes


> Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all 
> (local) buckets (not per bucket)
> ---
>
> Key: GEODE-2852
> URL: https://issues.apache.org/jira/browse/GEODE-2852
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> Currently, the timeout provided in LuceneServiceImpl.waitUntilFlushed() is 
> applied on a per bucket basis (in each member) within 
> BucketRegionQueue.waitUntilFlushed().
> This timeout needs to be applied across all (local primary) buckets 
> (WaitUntilParallelGatewaySenderFlushedCoordinator).  
> Once the timeout is reached, return false if all WaitUntilFlushed Callables 
> have not been invoked.



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

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Hitesh Khamesra]

>>> a. Now these two chunks will go continuous. 

>>They would appear continuous to the object serialization layer.

One benefit of messageHeader with chunk is that, it gives us ability to write 
different messages(multiplexing) on same socket. And if thread is ready it can 
write its message. Though we are not there yet, but that will require for 
single socket async architecture.





From: Jacob Barrett 
To: dev@geode.apache.org 
Cc: Anthony Baker 
Sent: Thursday, May 4, 2017 12:48 PM
Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal





Sent from my iPhone

> On May 4, 2017, at 12:03 PM, Hitesh Khamesra  
> wrote:
> 
> And len 0 would indicate end of the message? 
> 
> 
> a. Now these two chunks will go continuous. 

They would appear continuous to the object serialization layer.



> 
> 
> b. If its PDX encoded then pdx header(1byte:pdxid 4byte:len 4byte:typeId) 
> requires size of all pdx serialized bytes. So we know "size" of data upfront 
> here. 

We could define the InputSource for the Value part such that 
InputSource.getLength() could return a known length or -1 if length is unknown. 
If length is reasonable then the object could be encoded with a single chuck of 
size InputSource.getLength() followed by a 0 chunk. 

Clients are likely dealing with domain objects where the serialize length is 
not known until serialization is complete. This would require buffering to get 
the length. Buffering adds heap pressure and latency.

-Jake

[jira] [Commented] (GEODE-2852) Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all (local) buckets (not per bucket)

[ASF GitHub Bot (JIRA)]

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

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

Github user ladyVader closed the pull request at:

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


> Enforce WaitUntilFlushedFunction.waitUntilFlushed() timeout across all 
> (local) buckets (not per bucket)
> ---
>
> Key: GEODE-2852
> URL: https://issues.apache.org/jira/browse/GEODE-2852
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> Currently, the timeout provided in LuceneServiceImpl.waitUntilFlushed() is 
> applied on a per bucket basis (in each member) within 
> BucketRegionQueue.waitUntilFlushed().
> This timeout needs to be applied across all (local primary) buckets 
> (WaitUntilParallelGatewaySenderFlushedCoordinator).  
> Once the timeout is reached, return false if all WaitUntilFlushed Callables 
> have not been invoked.



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

[GitHub] geode pull request #490: Feature/geode 2852

[ladyVader]

Github user ladyVader closed the pull request at:

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


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

[jira] [Commented] (GEODE-2853) Change of locator list request interval

[ASF GitHub Bot (JIRA)]

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/483
  
Thanks for the suggestion. I fixed that.
@bschuchardt @kirklund


> Change of locator list request interval
> ---
>
> Key: GEODE-2853
> URL: https://issues.apache.org/jira/browse/GEODE-2853
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> If you connect to a Geode cluster using a locator from the client, the 
> locator list request will be executed at regular intervals in the background 
> thread. I want to tune this interval. I understand that this interval can be 
> changed by the ping-interval of the Pool attribute. However, I think that 
> ping-interval originally sets the ping interval for health check to the cache 
> server. Therefore, it is not possible to change the locator list request 
> interval without changing the health check interval to the cache server. So,I 
> want to add a java system property that can change the locator list request 
> interval.
> The locator list request interval is determined by the following priority 
> order.
>   1. java system property "gemfire.LOCATOR_UPDATE_INTERVAL"
>   2. ping-interval of the Pool attribute
> In addition, when changing this time, the background thread is activated only 
> when this value is a positive value.



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

[GitHub] geode issue #483: GEODE-2853: Change of locator list request interval

[masaki-yamakawa]

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/483
  
Thanks for the suggestion. I fixed that.
@bschuchardt @kirklund


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

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Hitesh Khamesra]

And len 0 would indicate end of the message? 


a. Now these two chunks will go continuous. 


b. If its PDX encoded then pdx header(1byte:pdxid 4byte:len 4byte:typeId) 
requires size of all pdx serialized bytes. So we know "size" of data upfront 
here. 


c. Lets say region value is just long byte[]:  Then we have "size" to send the 
message.


So in both cases we know the "size" of serialized bytes(payload). So possibly 
we don't need to chunk that message and let tcp take care of it?


It seems we should walk through some more usecases to understand this better.



Thanks.
Hitesh




From: Anthony Baker 
To: Hitesh Khamesra  
Cc: "dev@geode.apache.org" 
Sent: Thursday, May 4, 2017 11:20 AM
Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal



There would be one Message containing a single MessageHeader and a single 
MessageBody.  A PDX EncodedValue containing 1242 bytes that are chunked would 
look something like this:

PDX 1000 byte[1000] 242 byte[242] 0


Anthony



> On May 4, 2017, at 10:38 AM, Hitesh Khamesra  wrote:
> 
> Hi Anthony:
> 
> Help me to understand data chunking here?
> 
>>> bytes => arbitrary byte[] that can be chunked
> 
> Message => MessageHeader MessageBody
> 
> So lets say we want to send long byte[] into two chunks, then we will send 
> two messages? And other side will combine those two messages using 
> "correlationId" ?
> 
> Thanks.
> HItesh
> 
> 
> 
> 
> 
> From: Anthony Baker 
> To: dev@geode.apache.org 
> Cc: Hitesh Khamesra 
> Sent: Wednesday, May 3, 2017 5:42 PM
> Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
> 
> 
> 
> 
>> On May 3, 2017, at 1:33 PM, Galen M O'Sullivan  wrote:
>> 
>> On Tue, May 2, 2017 at 11:52 AM, Hitesh Khamesra <
>> hitesh...@yahoo.com.invalid> wrote:
>> 
>>> Absolutely its a implementation detail.
>>> 
>> This doesn't answer Dan's comment. Do you think fragmentation should be
>> taken care of by the TCP layer or the protocol should deal with it
>> specifically?
> 
> There’s some really good feedback and discussion in this thread!  Here are a 
> few thoughts:
> 
> 1) Optional metadata should be used for fields that are generally applicable 
> across all messages.  If a metadata field is required or only applies to a 
> small set of messages, it should become part of a message definition.  Of 
> course there’s some grey area here.
> 
> 2) I think we should pull out the message fragmentation support to avoid some 
> significant complexity.  We can later add a fragmentation / envelope layer on 
> top without disrupting the current proposal.  I do think we should add the 
> capability for chunking data (more on that below).
> 
> 3) I did not find any discussion of message pipelining (queuing multiple 
> requests on a socket without waiting for a response) or out-of-order 
> responses.  What is the plan for these capabilities and how will that affect 
> consistency?  What about retries?
> 
> 4) Following is an alternative definition with these characteristics:
> 
> - Serialized data can either be primitive or encoded values.  Encoded values 
> are chunked as needed to break up large objects into a series of smaller 
> parts.
> - Because values can be chunked, the size field is removed.  This allows the 
> message to be streamed to the socket incrementally.
> - The apiVersion is removed because we can just define a new body type with a 
> new apiId (e.g. GetRequest2 with aipId = 1292).
> - The GetRequest tells the server what kind of encoding the client is able to 
> understand.
> - The metadata map is not used for fields that belong in the message body.  I 
> think it’s much easier to write a spec without if statements :-)
> 
> Message => MessageHeader MessageBody
> 
> MessageHeader => correlationId metadata
>correlationId => integer
>metadata => count (key value)*
>count => integer
>key => string
>value => string
> 
> MessageBody => apiId body
>apiId => integer
>body => (see specific definitions)
> 
> GetRequest => 0 acceptEncoding key
>0 => the API id
>acceptEncoding => (define some encodings for byte[], JSON, PDX, *, etc)
>key => EncodedValue
> 
> GetResponse => 1 value
>1 => the API id
>value => EncodedValue
> 
> PutRequest => 2 eventId key value
>2 => the API id
>eventId => clientId threadId sequenceId
>clientId => string
>threadId => integer
>sequenceId => integer
>key => EncodedValue
>value => EncodedValue
> 
> EncodedValue => encoding (boolean | integer | number | string | ((length 
> bytes)* 0))
>encoding => (define some encodings for byte[], JSON, PDX, *, etc)
>boolean => TRUE or FALSE
>integer => a signed integer value
>number => a decimal value corresponding to IEEE 754
>string => UTF-8 text

[jira] [Commented] (GEODE-2611) Host geode-native docs on geode.apache.org

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2611:
--

This will be completed when we do the first geode-native release.

> Host geode-native docs on geode.apache.org
> --
>
> Key: GEODE-2611
> URL: https://issues.apache.org/jira/browse/GEODE-2611
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, native client
>Reporter: Anthony Baker
>
> Host the geode-native docs on geode.apache.org/docs instead of on pivotal.io. 
>  Update the link in README.md.



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

Re: Geode Native Release

[John Blum]

A good reason to use separate repos.  Individual components of Geode,
especially clear boundaries like Native Client, *Gfsh*, or Pulse, etc,
should be separately and independently releasable to provide a smoother
release cadence based on velocity and community need.

Then, using a Maven "BOM", you can tie all the independent (yet compatible)
versions together in 1 cohesive collection of artifacts for a particular
release of Geode.

You think all the SD modules in the "release train" have a same version?
No!

Case in point...

https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L21-L146

They all have the same "symbolic" version though...

https://github.com/spring-projects/spring-data-build/blob/1.9.3.RELEASE/bom/pom.xml#L6-L7

Which is what other projects (e.g. *Spring Boot*) use to pull in the SD
train...

https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L158

https://github.com/spring-projects/spring-boot/blob/v1.5.3.RELEASE/spring-boot-dependencies/pom.xml#L2088-L2094

While we don't typically release individual SD modules (though, it has been
known to occur [1]), we could.  But, we try to keep all modules in sync
with the train since all have a common core (*Spring Framework* / *Spring
Data Commons*), but they have all different versions.  Many other open
source projects operate the same way... Reactor.

$0.02

-John


[1]
https://github.com/spring-projects/spring-data-gemfire/tree/1.8.4.RELEASE-PATCH01


On Thu, May 4, 2017 at 11:23 AM, Anthony Baker  wrote:

> Let’s say we release geode-native along with geode 1.2.  When it comes
> time to release 1.3 (and geode-native is not yet ready) we would be
> creating release branches from:
>
> geode:  develop
> geode-example:  develop
> geode-native:   release/v1.2.0
>
> Anthony
>
> > On May 4, 2017, at 11:16 AM, Jacob Barrett  wrote:
> >
> > I don't see how they are different branches? If geode-Native has
> release/1.2 and Geode has release/1.2?
> >
> > Sent from my iPhone
> >
> >> On May 4, 2017, at 10:21 AM, Anthony Baker  wrote:
> >>
> >> I think it’s confusing to cut a release from different branches for
> geode, geode-examples, and geode-native but I don’t have a better idea.
> >>
> >> +0
> >>
> >> Anthony
> >>
> >>> On May 4, 2017, at 7:29 AM, Jacob Barrett  wrote:
> >>>
> >>> All,
> >>>
> >>> I want to start the discussion on releasing Geode Native C++ and .NET
> >>> clients with the next or near future Geode release.
> >>>
> >>> There are a few house keeping items left in the source release JIRA
> [1]. It
> >>> would be great to get some help completing these tasks.
> >>>
> >>> If we start with a source only release, which Geode release should we
> >>> target? Since it is "adding feature" it seems it makes the most sense
> to do
> >>> it as part of a minor release, say 1.2.
> >>>
> >>> To throw a little wrench in it all. There are some serious changes
> coming
> >>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
> >>> replacing all non-standard concurrency methods. These changes won't be
> >>> compatible with sources written against previous releases of
> geode-native,
> >>> thus suggesting they will need a major rev shortly. My suggestion
> would be
> >>> to cut a release branch now on geode-native for 1.2 and get it ready
> for
> >>> source release. Backport any changes on the release branch to develop.
> That
> >>> leaves develop open for marching forward with what would be a 2.0 set
> of
> >>> sources. Any release of Geode 1.x would just include the geode-native
> >>> release/1.x branches until Geode 2.0.
> >>>
> >>> Thoughts and feedback?
> >>>
> >>> [1] https://issues.apache.org/jira/browse/GEODE-1416
> >>> [2] https://issues.apache.org/jira/browse/GEODE-2807
> >>> [3] https://issues.apache.org/jira/browse/GEODE-2729
> >>> [4] https://issues.apache.org/jira/browse/GEODE-2493
> >>>
> >>> -Jake
> >>
>
>


-- 
-John
john.blum10101 (skype)

[jira] [Updated] (GEODE-1996) There are confusing references to "multicast" for locators ports

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-1996:
---
Description: 
The documentation seems to contain confusing terms when it comes to locators 
and locators ports. In the documentation, we state that port the locator runs 
on as a *multicast* port. This is incorrect as the multicast port is configured 
by the property `mcast-port`.

http://geode.apache.org/docs/guide/11/configuring/running/firewalls_ports.html 
- mentions ??By default, if not otherwise specified, Geode locators use the 
default multicast port 10334.??

We might have to scour the documentation for the term multicast and validate 
that this is the correct usage for that scenario

  was:
The documentation seems to contain confusing terms when it comes to locators 
and locators ports. In the documentation, we state that port the locator runs 
on as a *multicast* port. This is incorrect as the multicast port is configured 
by the property `mcast-port`.

http://geode.docs.pivotal.io/docs/configuring/running/firewalls_ports.html - 
mentions ??By default, if not otherwise specified, Geode locators use the 
default multicast port 10334.??

We might have to scour the documentation for the term multicast and validate 
that this is the correct usage for that scenario


> There are confusing references to "multicast" for locators ports
> 
>
> Key: GEODE-1996
> URL: https://issues.apache.org/jira/browse/GEODE-1996
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Udo Kohlmeyer
>Assignee: Dave Barnes
>
> The documentation seems to contain confusing terms when it comes to locators 
> and locators ports. In the documentation, we state that port the locator runs 
> on as a *multicast* port. This is incorrect as the multicast port is 
> configured by the property `mcast-port`.
> http://geode.apache.org/docs/guide/11/configuring/running/firewalls_ports.html
>  - mentions ??By default, if not otherwise specified, Geode locators use the 
> default multicast port 10334.??
> We might have to scour the documentation for the term multicast and validate 
> that this is the correct usage for that scenario



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

Re: Geode Native Release

[Anthony Baker]

Let’s say we release geode-native along with geode 1.2.  When it comes time to 
release 1.3 (and geode-native is not yet ready) we would be creating release 
branches from:

geode:  develop
geode-example:  develop
geode-native:   release/v1.2.0

Anthony

> On May 4, 2017, at 11:16 AM, Jacob Barrett  wrote:
> 
> I don't see how they are different branches? If geode-Native has release/1.2 
> and Geode has release/1.2?
> 
> Sent from my iPhone
> 
>> On May 4, 2017, at 10:21 AM, Anthony Baker  wrote:
>> 
>> I think it’s confusing to cut a release from different branches for geode, 
>> geode-examples, and geode-native but I don’t have a better idea.
>> 
>> +0
>> 
>> Anthony
>> 
>>> On May 4, 2017, at 7:29 AM, Jacob Barrett  wrote:
>>> 
>>> All,
>>> 
>>> I want to start the discussion on releasing Geode Native C++ and .NET
>>> clients with the next or near future Geode release.
>>> 
>>> There are a few house keeping items left in the source release JIRA [1]. It
>>> would be great to get some help completing these tasks.
>>> 
>>> If we start with a source only release, which Geode release should we
>>> target? Since it is "adding feature" it seems it makes the most sense to do
>>> it as part of a minor release, say 1.2.
>>> 
>>> To throw a little wrench in it all. There are some serious changes coming
>>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
>>> replacing all non-standard concurrency methods. These changes won't be
>>> compatible with sources written against previous releases of geode-native,
>>> thus suggesting they will need a major rev shortly. My suggestion would be
>>> to cut a release branch now on geode-native for 1.2 and get it ready for
>>> source release. Backport any changes on the release branch to develop. That
>>> leaves develop open for marching forward with what would be a 2.0 set of
>>> sources. Any release of Geode 1.x would just include the geode-native
>>> release/1.x branches until Geode 2.0.
>>> 
>>> Thoughts and feedback?
>>> 
>>> [1] https://issues.apache.org/jira/browse/GEODE-1416
>>> [2] https://issues.apache.org/jira/browse/GEODE-2807
>>> [3] https://issues.apache.org/jira/browse/GEODE-2729
>>> [4] https://issues.apache.org/jira/browse/GEODE-2493
>>> 
>>> -Jake
>> 

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Anthony Baker]

There would be one Message containing a single MessageHeader and a single 
MessageBody.  A PDX EncodedValue containing 1242 bytes that are chunked would 
look something like this:

PDX 1000 byte[1000] 242 byte[242] 0


Anthony


> On May 4, 2017, at 10:38 AM, Hitesh Khamesra  wrote:
> 
> Hi Anthony:
> 
> Help me to understand data chunking here?
> 
>>> bytes => arbitrary byte[] that can be chunked
> 
> Message => MessageHeader MessageBody
> 
> So lets say we want to send long byte[] into two chunks, then we will send 
> two messages? And other side will combine those two messages using 
> "correlationId" ?
> 
> Thanks.
> HItesh
> 
> 
> 
> 
> 
> From: Anthony Baker 
> To: dev@geode.apache.org 
> Cc: Hitesh Khamesra 
> Sent: Wednesday, May 3, 2017 5:42 PM
> Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal
> 
> 
> 
> 
>> On May 3, 2017, at 1:33 PM, Galen M O'Sullivan  wrote:
>> 
>> On Tue, May 2, 2017 at 11:52 AM, Hitesh Khamesra <
>> hitesh...@yahoo.com.invalid> wrote:
>> 
>>> Absolutely its a implementation detail.
>>> 
>> This doesn't answer Dan's comment. Do you think fragmentation should be
>> taken care of by the TCP layer or the protocol should deal with it
>> specifically?
> 
> There’s some really good feedback and discussion in this thread!  Here are a 
> few thoughts:
> 
> 1) Optional metadata should be used for fields that are generally applicable 
> across all messages.  If a metadata field is required or only applies to a 
> small set of messages, it should become part of a message definition.  Of 
> course there’s some grey area here.
> 
> 2) I think we should pull out the message fragmentation support to avoid some 
> significant complexity.  We can later add a fragmentation / envelope layer on 
> top without disrupting the current proposal.  I do think we should add the 
> capability for chunking data (more on that below).
> 
> 3) I did not find any discussion of message pipelining (queuing multiple 
> requests on a socket without waiting for a response) or out-of-order 
> responses.  What is the plan for these capabilities and how will that affect 
> consistency?  What about retries?
> 
> 4) Following is an alternative definition with these characteristics:
> 
> - Serialized data can either be primitive or encoded values.  Encoded values 
> are chunked as needed to break up large objects into a series of smaller 
> parts.
> - Because values can be chunked, the size field is removed.  This allows the 
> message to be streamed to the socket incrementally.
> - The apiVersion is removed because we can just define a new body type with a 
> new apiId (e.g. GetRequest2 with aipId = 1292).
> - The GetRequest tells the server what kind of encoding the client is able to 
> understand.
> - The metadata map is not used for fields that belong in the message body.  I 
> think it’s much easier to write a spec without if statements :-)
> 
> Message => MessageHeader MessageBody
> 
> MessageHeader => correlationId metadata
>correlationId => integer
>metadata => count (key value)*
>count => integer
>key => string
>value => string
> 
> MessageBody => apiId body
>apiId => integer
>body => (see specific definitions)
> 
> GetRequest => 0 acceptEncoding key
>0 => the API id
>acceptEncoding => (define some encodings for byte[], JSON, PDX, *, etc)
>key => EncodedValue
> 
> GetResponse => 1 value
>1 => the API id
>value => EncodedValue
> 
> PutRequest => 2 eventId key value
>2 => the API id
>eventId => clientId threadId sequenceId
>clientId => string
>threadId => integer
>sequenceId => integer
>key => EncodedValue
>value => EncodedValue
> 
> EncodedValue => encoding (boolean | integer | number | string | ((length 
> bytes)* 0))
>encoding => (define some encodings for byte[], JSON, PDX, *, etc)
>boolean => TRUE or FALSE
>integer => a signed integer value
>number => a decimal value corresponding to IEEE 754
>string => UTF-8 text
>bytes => arbitrary byte[] that can be chunked
> 
> 
> Anthony

Re: Geode Native Release

[Jacob Barrett]

I don't see how they are different branches? If geode-Native has release/1.2 
and Geode has release/1.2?

Sent from my iPhone

> On May 4, 2017, at 10:21 AM, Anthony Baker  wrote:
> 
> I think it’s confusing to cut a release from different branches for geode, 
> geode-examples, and geode-native but I don’t have a better idea.
> 
> +0
> 
> Anthony
> 
>> On May 4, 2017, at 7:29 AM, Jacob Barrett  wrote:
>> 
>> All,
>> 
>> I want to start the discussion on releasing Geode Native C++ and .NET
>> clients with the next or near future Geode release.
>> 
>> There are a few house keeping items left in the source release JIRA [1]. It
>> would be great to get some help completing these tasks.
>> 
>> If we start with a source only release, which Geode release should we
>> target? Since it is "adding feature" it seems it makes the most sense to do
>> it as part of a minor release, say 1.2.
>> 
>> To throw a little wrench in it all. There are some serious changes coming
>> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
>> replacing all non-standard concurrency methods. These changes won't be
>> compatible with sources written against previous releases of geode-native,
>> thus suggesting they will need a major rev shortly. My suggestion would be
>> to cut a release branch now on geode-native for 1.2 and get it ready for
>> source release. Backport any changes on the release branch to develop. That
>> leaves develop open for marching forward with what would be a 2.0 set of
>> sources. Any release of Geode 1.x would just include the geode-native
>> release/1.x branches until Geode 2.0.
>> 
>> Thoughts and feedback?
>> 
>> [1] https://issues.apache.org/jira/browse/GEODE-1416
>> [2] https://issues.apache.org/jira/browse/GEODE-2807
>> [3] https://issues.apache.org/jira/browse/GEODE-2729
>> [4] https://issues.apache.org/jira/browse/GEODE-2493
>> 
>> -Jake
> 

Re: Review Request 58996: GEODE-2876: Add logging to diagnose CI failure

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On May 4, 2017, 5:12 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58996/
> ---
> 
> (Updated May 4, 2017, 5:12 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2876: Add logging to diagnose CI failure
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
> 
> 
> Diff: https://reviews.apache.org/r/58996/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Build failed in Jenkins: Geode-nightly #825

[Apache Jenkins Server]

See 


Changes:

[nnag] GEODE-2828: AEQ created before the Lucene user regions

[eshu] GEODE-2847: Get correct version tags for retried bulk operations

[eshu] GEODE-2847: Get correct version tags for retried bulk operation

[gzhou] geode-2848: when found all the partitioned region is destroyed, add back

[bschuchardt] GEODE-2875  shutdown is taking as long as 20 seconds

[dschneider] GEODE-2864: remove meaningless tx warning message

[jstewart] GEODE-2837: Start server creates specified working dir if necessary

[jstewart] GEODE-2837: Test relative path as argument to --dir

[adongre] GEODE-254: Removed deprecated Region.keys and Region.entries This 
closes

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

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

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

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

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

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Hitesh Khamesra]

Hi Anthony:

Help me to understand data chunking here?

>> bytes => arbitrary byte[] that can be chunked

Message => MessageHeader MessageBody

So lets say we want to send long byte[] into two chunks, then we will send two 
messages? And other side will combine those two messages using "correlationId" ?

Thanks.
HItesh





From: Anthony Baker 
To: dev@geode.apache.org 
Cc: Hitesh Khamesra 
Sent: Wednesday, May 3, 2017 5:42 PM
Subject: Re: [gemfire-dev] New Client-Server Protocol Proposal




> On May 3, 2017, at 1:33 PM, Galen M O'Sullivan  wrote:
> 
> On Tue, May 2, 2017 at 11:52 AM, Hitesh Khamesra <
> hitesh...@yahoo.com.invalid> wrote:
> 
>> Absolutely its a implementation detail.
>> 
> This doesn't answer Dan's comment. Do you think fragmentation should be
> taken care of by the TCP layer or the protocol should deal with it
> specifically?

There’s some really good feedback and discussion in this thread!  Here are a 
few thoughts:

1) Optional metadata should be used for fields that are generally applicable 
across all messages.  If a metadata field is required or only applies to a 
small set of messages, it should become part of a message definition.  Of 
course there’s some grey area here.

2) I think we should pull out the message fragmentation support to avoid some 
significant complexity.  We can later add a fragmentation / envelope layer on 
top without disrupting the current proposal.  I do think we should add the 
capability for chunking data (more on that below).

3) I did not find any discussion of message pipelining (queuing multiple 
requests on a socket without waiting for a response) or out-of-order responses. 
 What is the plan for these capabilities and how will that affect consistency?  
What about retries?

4) Following is an alternative definition with these characteristics:

- Serialized data can either be primitive or encoded values.  Encoded values 
are chunked as needed to break up large objects into a series of smaller parts.
- Because values can be chunked, the size field is removed.  This allows the 
message to be streamed to the socket incrementally.
- The apiVersion is removed because we can just define a new body type with a 
new apiId (e.g. GetRequest2 with aipId = 1292).
- The GetRequest tells the server what kind of encoding the client is able to 
understand.
- The metadata map is not used for fields that belong in the message body.  I 
think it’s much easier to write a spec without if statements :-)

Message => MessageHeader MessageBody

MessageHeader => correlationId metadata
correlationId => integer
metadata => count (key value)*
count => integer
key => string
value => string

MessageBody => apiId body
apiId => integer
body => (see specific definitions)

GetRequest => 0 acceptEncoding key
0 => the API id
acceptEncoding => (define some encodings for byte[], JSON, PDX, *, etc)
key => EncodedValue

GetResponse => 1 value
1 => the API id
value => EncodedValue

PutRequest => 2 eventId key value
2 => the API id
eventId => clientId threadId sequenceId
clientId => string
threadId => integer
sequenceId => integer
key => EncodedValue
value => EncodedValue

EncodedValue => encoding (boolean | integer | number | string | ((length 
bytes)* 0))
encoding => (define some encodings for byte[], JSON, PDX, *, etc)
boolean => TRUE or FALSE
integer => a signed integer value
number => a decimal value corresponding to IEEE 754
string => UTF-8 text
bytes => arbitrary byte[] that can be chunked


Anthony

Re: Geode Native Release

[Anthony Baker]

I think it’s confusing to cut a release from different branches for geode, 
geode-examples, and geode-native but I don’t have a better idea.

+0

Anthony

> On May 4, 2017, at 7:29 AM, Jacob Barrett  wrote:
> 
> All,
> 
> I want to start the discussion on releasing Geode Native C++ and .NET
> clients with the next or near future Geode release.
> 
> There are a few house keeping items left in the source release JIRA [1]. It
> would be great to get some help completing these tasks.
> 
> If we start with a source only release, which Geode release should we
> target? Since it is "adding feature" it seems it makes the most sense to do
> it as part of a minor release, say 1.2.
> 
> To throw a little wrench in it all. There are some serious changes coming
> with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
> replacing all non-standard concurrency methods. These changes won't be
> compatible with sources written against previous releases of geode-native,
> thus suggesting they will need a major rev shortly. My suggestion would be
> to cut a release branch now on geode-native for 1.2 and get it ready for
> source release. Backport any changes on the release branch to develop. That
> leaves develop open for marching forward with what would be a 2.0 set of
> sources. Any release of Geode 1.x would just include the geode-native
> release/1.x branches until Geode 2.0.
> 
> Thoughts and feedback?
> 
> [1] https://issues.apache.org/jira/browse/GEODE-1416
> [2] https://issues.apache.org/jira/browse/GEODE-2807
> [3] https://issues.apache.org/jira/browse/GEODE-2729
> [4] https://issues.apache.org/jira/browse/GEODE-2493
> 
> -Jake

Re: Review Request 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On May 3, 2017, 10:10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 3, 2017, 10:10 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
> Howe, and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache
> 
> * misc cleanup of code where possible
> 
> I'm running full regression and precheckin. Sorry this is so many files -- 
> I'm not sure this is even practical to review :/
> 
> I'd like to avoid any further cleanup and just get this committed asap to 
> avoid conflicts. Let's hold off on throwing more changes on top of this if 
> you see more lines of code in a file that you'd like cleaned up. I obviously 
> want to fix problems in any code that I touched though!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCALocalTransaction.java
>  112f2fa44478f00782bcb717d8cb75233c979dce 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCAManagedConnection.java
>  520f7e245ca3493d54ac661da29f58a3dfc71189 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 58518f4f5d43b3fe214a1218703360928efdee52 
>   geode-core/src/main/java/org/apache/geode/admin/GemFireMemberStatus.java 
> 5b4e59ef341007a4e42cd5a10b4e8a2eb4d18deb 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/CacheHealthEvaluator.java
>  f7ff9ede1e074425ce7aa7bed1a63c72c5174bf6 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FinishBackupRequest.java
>  25abd7ee5d346d764d68339ae6c03b2cffc63bc8 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FlushToDiskRequest.java
>  ff6dd9d2088124203842a06d3a794e00a5636246 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/MemberHealthEvaluator.java
>  951b364718f43c5efc85c0f0f0e5d54e24d87ced 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/PrepareBackupRequest.java
>  7025721180cb6b158cff4b21bfcea6549780ccd3 
>   geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java 
> 1a46f241a7b3a4bbbd47da70c227b3e3ea237fd0 
>   geode-core/src/main/java/org/apache/geode/cache/CacheClosedException.java 
> b24bc2fc5ad39737e908f9df2704b62728222629 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 0772dcf86b3d3ea9eebfe1d324c8fa043fa8ac79 
>   geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
> 57a1a465c1bd0d91d8bb83ad2b97db1f2efbb025 
>   geode-core/src/main/java/org/apache/geode/cache/GemFireCache.java 
> e60bc59a88051ac11a863ea10be3e2bf07e4cbe7 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 
> 3eef5438e78a94acd669764e88daaafe6f5fa388 
>   geode-core/src/main/java/org/apache/geode/cache/RegionFactory.java 
> 3a2e9f68c96f9e4aae5a837e175014a3598f69ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/TransactionDataRebalancedException.java
>  fded49f3c00772f38bac14bc57fa4614144930c1 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  1a4052b27688c8e04addf6987ce39ea006f71cc5 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  0def5d283e359b1766fc90dfa05903526c672b0b 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  e799880d715ed1fba65df305cf37e92f27db54ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/SerialAsyncEventQueueImpl.java
>  9252dc745b848ea7a5aa8793a1fdb3a3c004c7ee 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  e72cbff048b5a7ecb24594382d776feaa8e0f4bd 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
>  ef676673046c32f68558f85516c674f7dcc6e982 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
>  a494138316d8538f3aebeffb7075bb2db33b6532 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecutablePool.java
>  54521d52879088eeceea15a44933c909d536b76f 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteFunctionOp.java
>  d32e0f41bd7a939241227137e2218eef72ccfc56 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionOp.java
>  01f908151ad08692bbb0b493826632fcb02de15f 
>   
> 

Review Request 58996: GEODE-2876: Add logging to diagnose CI failure

[Jared Stewart]

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

Review request for geode.


Repository: geode


Description
---

GEODE-2876: Add logging to diagnose CI failure


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e1425d71af9d2ea59046b17afd70ad30dd68 


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


Testing
---


Thanks,

Jared Stewart

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Bruce Schuchardt]

It's becoming clear that the document needs a section on EventIds.

EventIds aren't opaque to the server.  They are comparable objects and 
are used by the cache to prevent replay of older (operation eventId < 
recorded eventId) operations on the cache and on subscription queues.  
They are also used to prevent sending operations originating from a 
client back to that client in its subscription queue.


A thread's sequenceId should be incremented for each operation sent to 
the server.


In my opinion EventIds are optional for clients and only need to be 
implemented if clients are going to retry operations.  If a client 
doesn't send an EventId to the server one will be generated on the 
server for the operation.


Le 5/4/2017 à 8:46 AM, Jacob Barrett a écrit :

The eventId is really just a once token right? Meaning that its rather
opaque to the server and intended to keep the server from replaying a
request that the client may have retried that was actually successful. If
it is opaque to the server then why encode all these specific identifiers?
Seems to me it could be optional for one and could simply be a variant int
or byte[]. The server just needs to stash the once tokens and make sure it
doesn't get a duplicate on this client stream.

[jira] [Commented] (GEODE-2814) Native client test framework uses Xerces which depends on Curl

[ASF GitHub Bot (JIRA)]

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

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

GitHub user gemfire-ci opened a pull request:

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

GEODE-2814 Remove curl dependency from native client build

Signed-off-by: Scott Jewell 

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

$ git pull https://github.com/apache/geode-native GEODE-2814

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

https://github.com/apache/geode-native/pull/96.patch

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

This closes #96


commit 1b93cd9a05272c644dad622b171bdbc46eaca474
Author: Dick Cavender 
Date:   2017-04-24T17:37:59Z

GEODE-2814 Remove curl dependency from native client build

Signed-off-by: Scott Jewell 




> Native client test framework uses Xerces which depends on Curl
> --
>
> Key: GEODE-2814
> URL: https://issues.apache.org/jira/browse/GEODE-2814
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Jens Deppe
> Fix For: 1.1.1
>
>
> The native client driver uses Xerces which is being built with a dependency 
> on Curl.  This can cause link problems due to availability of compatible 
> version
> of Curl being available.  Curl is not utilized by the Framework/Xerces and can
> be built without Curl.  Removing Curl dependency will avoid potential problems
> in the future.



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

[GitHub] geode-native pull request #96: GEODE-2814 Remove curl dependency from native...

[gemfire-ci]

GitHub user gemfire-ci opened a pull request:

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

GEODE-2814 Remove curl dependency from native client build

Signed-off-by: Scott Jewell 

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

$ git pull https://github.com/apache/geode-native GEODE-2814

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

https://github.com/apache/geode-native/pull/96.patch

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

This closes #96


commit 1b93cd9a05272c644dad622b171bdbc46eaca474
Author: Dick Cavender 
Date:   2017-04-24T17:37:59Z

GEODE-2814 Remove curl dependency from native client build

Signed-off-by: Scott Jewell 




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

Re: Review Request 58888: GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/internal/cache/DistTXPrecommitMessage.java
Line 468 (original), 461 (patched)


Seems inconsistent to rename this inner class, "...Precommit..." -> 
"...PreCommit..." when the class it's in remains as "...Precommit..."

edit: This can probably be ignored if you've reverted the DistTX* changes


- Ken Howe


On May 3, 2017, 10:10 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5/
> ---
> 
> (Updated May 3, 2017, 10:10 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, Ken 
> Howe, and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632: change dependencies on GemFireCacheImpl to InternalCache
> 
> * misc cleanup of code where possible
> 
> I'm running full regression and precheckin. Sorry this is so many files -- 
> I'm not sure this is even practical to review :/
> 
> I'd like to avoid any further cleanup and just get this committed asap to 
> avoid conflicts. Let's hold off on throwing more changes on top of this if 
> you see more lines of code in a file that you'd like cleaned up. I obviously 
> want to fix problems in any code that I touched though!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCALocalTransaction.java
>  112f2fa44478f00782bcb717d8cb75233c979dce 
>   
> geode-core/src/jca/java/org/apache/geode/internal/ra/spi/JCAManagedConnection.java
>  520f7e245ca3493d54ac661da29f58a3dfc71189 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 58518f4f5d43b3fe214a1218703360928efdee52 
>   geode-core/src/main/java/org/apache/geode/admin/GemFireMemberStatus.java 
> 5b4e59ef341007a4e42cd5a10b4e8a2eb4d18deb 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/CacheHealthEvaluator.java
>  f7ff9ede1e074425ce7aa7bed1a63c72c5174bf6 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FinishBackupRequest.java
>  25abd7ee5d346d764d68339ae6c03b2cffc63bc8 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/FlushToDiskRequest.java
>  ff6dd9d2088124203842a06d3a794e00a5636246 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/MemberHealthEvaluator.java
>  951b364718f43c5efc85c0f0f0e5d54e24d87ced 
>   
> geode-core/src/main/java/org/apache/geode/admin/internal/PrepareBackupRequest.java
>  7025721180cb6b158cff4b21bfcea6549780ccd3 
>   geode-core/src/main/java/org/apache/geode/cache/AttributesFactory.java 
> 1a46f241a7b3a4bbbd47da70c227b3e3ea237fd0 
>   geode-core/src/main/java/org/apache/geode/cache/CacheClosedException.java 
> b24bc2fc5ad39737e908f9df2704b62728222629 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 0772dcf86b3d3ea9eebfe1d324c8fa043fa8ac79 
>   geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
> 57a1a465c1bd0d91d8bb83ad2b97db1f2efbb025 
>   geode-core/src/main/java/org/apache/geode/cache/GemFireCache.java 
> e60bc59a88051ac11a863ea10be3e2bf07e4cbe7 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 
> 3eef5438e78a94acd669764e88daaafe6f5fa388 
>   geode-core/src/main/java/org/apache/geode/cache/RegionFactory.java 
> 3a2e9f68c96f9e4aae5a837e175014a3598f69ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/TransactionDataRebalancedException.java
>  fded49f3c00772f38bac14bc57fa4614144930c1 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  1a4052b27688c8e04addf6987ce39ea006f71cc5 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  0def5d283e359b1766fc90dfa05903526c672b0b 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  e799880d715ed1fba65df305cf37e92f27db54ea 
>   
> geode-core/src/main/java/org/apache/geode/cache/asyncqueue/internal/SerialAsyncEventQueueImpl.java
>  9252dc745b848ea7a5aa8793a1fdb3a3c004c7ee 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  e72cbff048b5a7ecb24594382d776feaa8e0f4bd 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
>  ef676673046c32f68558f85516c674f7dcc6e982 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
>  a494138316d8538f3aebeffb7075bb2db33b6532 
>   
> 

[jira] [Commented] (GEODE-2812) Add API to get list of live locators

[ASF GitHub Bot (JIRA)]

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/475
  
Thanks for the suggestion. I'll fix that.
@kirklund


> Add API to get list of live locators
> 
>
> Key: GEODE-2812
> URL: https://issues.apache.org/jira/browse/GEODE-2812
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> There is a Geode cluster using a logical member group, and from the client, 
> the connection pool to the logical member group is connected using the 
> PoolFactory API at the timing when connection becomes necessary.
> At this time, even though the locator that was running at the initial 
> connection stops due to reasons such as regular maintenance etc., even if the 
> alternate locator is started before maintenance, I can not connect to the 
> locator in the static initial list.
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupA").create("pool1");
> # Geode cluster:start locator [ localhost:10335 ].
> # Geode cluster:stop locator [ localhost:10334 ].
> # Client side:PoolManager.createFactory().addLocator("localhost", 
> 10334).setServerGroup("GroupB").create("pool2");
> Therefore, I would like to decide the connection destination based on the 
> live locator list of another logical member group.
> I added an API that can get the list of live locators from the Pool. Use the 
> API as follows:
> {code:java|borderStyle=solid}
> Pool pool = PoolManager.createFactory()
>   .addLocator("localhost", 10334)
>   .setSubscriptionEnabled(true).setServerGroup("GroupA")
>   .create("GroupAPool");
> List = pool.getLiveLocators();
> {code}
> {quote}
> Note:
> The list of live locators gets the result of the UpdateLocatorListTask 
> periodically running in AutoConnectionSourceImpl.
> Therefore, whether or not it is alive will cause a time lag, depending on the 
> task execution interval.
> Also, the result of ExplicitConnectionSourceImpl without using a locator is 
> always empty.
> {quote}



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

[jira] [Created] (GEODE-2876) CI Failure: org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2876:


 Summary: CI Failure: 
org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest#testMultipleGfshClientToOneServer
 Key: GEODE-2876
 URL: https://issues.apache.org/jira/browse/GEODE-2876
 Project: Geode
  Issue Type: Bug
  Components: gfsh, management
Reporter: Jared Stewart


ConcurrentDeployDUnitTest is failing due to a parsing error.


{noformat}
Error
java.lang.AssertionError: An exception occurred during asynchronous invocation.
Stacktrace
java.lang.AssertionError: An exception occurred during asynchronous invocation.
at 
org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:148)
at 
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:341)
at 
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:364)
at 
org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest.testMultipleGfshClientToOneServer(ConcurrentDeployDUnitTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 

[jira] [Resolved] (GEODE-1734) Lucene search for a single entry is returning multiple results

[xiaojian zhou (JIRA)]

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

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

Fixed in GEODE-2241 revision 0182a1bb744d25fe490d142dfed7d9a6f20b2713

> Lucene search for a single entry is returning multiple results
> --
>
> Key: GEODE-1734
> URL: https://issues.apache.org/jira/browse/GEODE-1734
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: William Markito Oliveira
>Assignee: xiaojian zhou
>
> Searching for a unique entry is returning multiple results, although the key 
> is the same.  It should return a single result.
> {code}
> gfsh>lucene search --name=customerRegionAll 
> --queryStrings="firstName:Jdfmlevjenzwgd" --region=/customer 
> --defaultField=displayName
> key  |
>value   | score
>  | 
> -
>  | -
> 70dbdb7f-648e-415e-880d-15631f87a523 | 
> PDX[16777220,org.example.domain.model.CustomerEntity]{active=false, 
> addresses=.. | 12.798602
> 70dbdb7f-648e-415e-880d-15631f87a523 | 
> PDX[16777220,org.example.domain.model.CustomerEntity]{active=false, 
> addresses=.. | 12.798602
> 70dbdb7f-648e-415e-880d-15631f87a523 | 
> PDX[16777220,org.example.domain.model.CustomerEntity]{active=false, 
> addresses=.. | 12.798602
> {code}



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

[jira] [Resolved] (GEODE-2523) Collapse RegionTestableTypes combinations into a single enum types

[Jason Huynh (JIRA)]

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

Jason Huynh resolved GEODE-2523.

   Resolution: Fixed
 Assignee: Jason Huynh
Fix Version/s: 1.2.0

> Collapse RegionTestableTypes combinations into a single enum types
> --
>
> Key: GEODE-2523
> URL: https://issues.apache.org/jira/browse/GEODE-2523
> Project: Geode
>  Issue Type: Sub-task
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.2.0
>
>
> Currently, we have pairs of RegionTestableTypes that are used in the 
> LuceneDUnit tests.  These pairs are used to determine the datastore and 
> accessor region types.  However the pairings are generally 1 to 1.  So we 
> should be able to collapse the types into a single enum and remove the 
> parameterized methods.  Instead we should then be able to add the enum name 
> into the parameters themselves.
> So instead of having the following for a test case
>  @Parameters(method = "getListOfClientServerTypes")
> We could then have
>   @Parameters({"PARTITION", "ETC..."})
> we can probably use PARTITION and know that the corresponding client type is 
> PARTITION_PROXY.  That or we can change the enum to be explicit about the 
> pairing, such as PARTITION_WITH_PARTITION_PROXY.



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

[jira] [Resolved] (GEODE-1189) Should the LuceneQueryFactory create API throw a Lucene ParseException?

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-1189.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Should the LuceneQueryFactory create API throw a Lucene ParseException?
> ---
>
> Key: GEODE-1189
> URL: https://issues.apache.org/jira/browse/GEODE-1189
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> Or should {{Geode}} be wrapping {{Lucene}} exceptions with {{Geode}} 
> exceptions?
> Also, related to that, the {{LuceneQueryFactory create}} is defined like:
> {noformat}
> public  LuceneQuery create(String indexName, String regionName, 
> String queryString) throws ParseException;
> {noformat}
> But, the {{LuceneQueryFactoryImpl create}} method is defined without the 
> throws clause like:
> {noformat}
> public  LuceneQuery create(String indexName, String regionName, 
> String queryString)
> {noformat}



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

[jira] [Resolved] (GEODE-969) Various WAN dunit tests sometimes cause OOME during combineReports task

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-969.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Various WAN dunit tests sometimes cause OOME during combineReports task
> ---
>
> Key: GEODE-969
> URL: https://issues.apache.org/jira/browse/GEODE-969
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> The combineReports task sometimes throws a 'java.lang.OutOfMemoryError: Java 
> heap space' error when creating the JUnit test report like:
> {noformat}
> :combineReports
> All test reports at 
> /japan1/users/build/jenkins/blds/workspace/GemFire_develop_closed_CC/gemfire/closed/build/reports/combined
> FAILURE: Build failed with an exception.
> Where:
> Build file 
> '/japan1/users/build/jenkins/blds/workspace/GemFire_develop_closed_CC/gemfire/closed/pivotalgf-assembly/build.gradle'
>  line: 156
> What went wrong:
> Execution failed for task ':pivotalgf-assembly:legacyDunit'.
> > There were failing tests.
> Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output.
> BUILD FAILED
> Total time: 2 hrs 8 mins 51.811 secs
> Recording test results
> ERROR: Publisher 'Publish JUnit test result report' aborted due to exception:
> java.io.IOException: remote file operation failed: 
> /japan1/users/build/jenkins/blds/workspace/GemFire_develop_closed_CC at 
> hudson.remoting.Channel@a3f9b9e:Japan: java.io.IOException: Remote call on 
> Japan failed
> at hudson.FilePath.act(FilePath.java:987)
> at hudson.FilePath.act(FilePath.java:969)
> at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
> at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
> at 
> hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
> at 
> hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:75)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
> at 
> hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
> at 
> hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
> at hudson.model.Build$BuildExecution.post2(Build.java:185)
> at 
> hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
> at hudson.model.Run.execute(Run.java:1766)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> at hudson.model.ResourceController.execute(ResourceController.java:98)
> at hudson.model.Executor.run(Executor.java:408)
> Caused by: java.io.IOException: Remote call on Japan failed
> at hudson.remoting.Channel.call(Channel.java:786)
> at hudson.FilePath.act(FilePath.java:980)
> ... 14 more
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at 
> com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(XMLStringBuffer.java:208)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(XMLEntityScanner.java:1378)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(XMLDocumentFragmentScannerImpl.java:1654)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3020)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:117)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
> at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
> at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
> at 
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at 
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649)
> at org.dom4j.io.SAXReader.read(SAXReader.java:465)
> at org.dom4j.io.SAXReader.read(SAXReader.java:264)
> at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:123)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:282)
> at hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:228)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:163)
> at hudson.tasks.junit.TestResult.parse(TestResult.java:146)
> at hudson.tasks.junit.TestResult.(TestResult.java:122)
> at 
> 

[jira] [Resolved] (GEODE-2612) Add option to invoke callbacks while loading a snapshot

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-2612.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Add option to invoke callbacks while loading a snapshot
> ---
>
> Key: GEODE-2612
> URL: https://issues.apache.org/jira/browse/GEODE-2612
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> As a work-around to recreating a lucene index (which is not currently 
> supported), the recommendation is to:
> - export user region
> - destroy indexes and user region
> - recreate index
> - recreate user region
> - import user region
> The lucene index is populated using an hidden AsyncEventQueue, but currently 
> import doesn't invoke callbacks. This feature request is to add an option to 
> SnapshotOptions to cause callbacks to be invoked, so that the index is 
> repopulated during import.



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

[jira] [Resolved] (GEODE-2553) After deleting and recreating my Lucene index and region, my Lucene query hung.

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-2553.
--
Resolution: Fixed

> After deleting and recreating my Lucene index and region, my Lucene query 
> hung.
> ---
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



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

[jira] [Resolved] (GEODE-2230) LuceneIndex.waitUntilFlushed should not have to wait for the queue to be completely empty

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-2230.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> LuceneIndex.waitUntilFlushed should not have to wait for the queue to be 
> completely empty
> -
>
> Key: GEODE-2230
> URL: https://issues.apache.org/jira/browse/GEODE-2230
> Project: Geode
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Dan Smith
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> We added a function to LuceneIndex to wait until updates are flushed to the 
> index with GEODE-1351.
> Unfortunately, the current approach has a few problems. It just waits in a 
> loop polling the size of the queue until it reaches zero. If someone uses 
> this method while the system is constantly receiving updates, the queue may 
> never reach zero.
> It would be better if this method could wait until any data at the time the 
> method was called was completely flushed.
> One way to accomplish this might be to send a function or message to all of 
> the members holding the async event queue for the lucene index. The function 
> could capture the current tail of the queue and wait until that event is 
> dispatched.



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

Re: [gemfire-dev] New Client-Server Protocol Proposal

[Jacob Barrett]

+1

On Wed, May 3, 2017 at 5:43 PM Anthony Baker  wrote:

>
> 2) I think we should pull out the message fragmentation support to avoid
> some significant complexity.  We can later add a fragmentation / envelope
> layer on top without disrupting the current proposal.  I do think we should
> add the capability for chunking data (more on that below).
>

+10 Like any good engineering practice we need to keep objects well
encapsulated and focused on their singular task. A message would not be
represented as a object of "partials" but as a whole message object, so why
treat it any differently when serialized. The layer below it can chunk it
if necessary. Initially between the message (lowest level in our stack) and
the TCP socket is nothing. TCP will fragment as needed, full message is
delivered up the stack. If in the future we ant to
mulitchannel/interleave/pipeline (whatever you want to call it) we can
negotiate the support with the client and inject a layer between the
message and TCP layers that identifies unique streams of data channels. In
the interim, the naive approach to multiple channels is to open a second
socket. The important thing is that at the message layer it doesn't know
and doesn't care.


> 4) Following is an alternative definition with these characteristics:
>
> - Serialized data can either be primitive or encoded values.  Encoded
> values are chunked as needed to break up large objects into a series of
> smaller parts.
>
+1

> - Because values can be chunked, the size field is removed.  This allows
> the message to be streamed to the socket incrementally.
>
+1

> - The apiVersion is removed because we can just define a new body type
> with a new apiId (e.g. GetRequest2 with aipId = 1292).
>
+1 Think of the message as a class, you don't want to have class that has
more than a single personality. If the first argument to your class
(version) is the personality then you need to think about a new class. You
don't want the writer of the protocol to have to deduce the personality of
the object based on an argument and then have to decide which fields are
require or optional or obsolete. By making a new message you strongly type
the messages both in definition and in implementation.


> - The GetRequest tells the server what kind of encoding the client is able
> to understand.
>
+ 1 I would suggest that a default ordered list be established at initial
handshake. If a list is not provided at handshake then ALL are supported.
Then on individual request messages if the list of encodings is given then
it overrides the list allowed for that single request. If no list is
provided on the request the handshake negotiated list is assumed. If a
value being returned is not encoded in any of the encodings listed then it
is transcoded to the highest priority encoding with an available transcoder
between the source and destination encoding.

GetRequest => 0 acceptEncoding key
> 0 => the API id
> acceptEncoding => (define some encodings for byte[], JSON, PDX, *, etc)
> key => EncodedValue
>
Change: acceptedEncodings => encodingId*
Would it make sense to make 'key' a 'key+' or does a GetAllRequest and
GetAllResponse vary that much from GetRequest and GetResponse?

PutRequest => 2 eventId key value
> 2 => the API id
> eventId => clientId threadId sequenceId
> clientId => string
> threadId => integer
> sequenceId => integer
> key => EncodedValue
> value => EncodedValue
>

The eventId is really just a once token right? Meaning that its rather
opaque to the server and intended to keep the server from replaying a
request that the client may have retried that was actually successful. If
it is opaque to the server then why encode all these specific identifiers?
Seems to me it could be optional for one and could simply be a variant int
or byte[]. The server just needs to stash the once tokens and make sure it
doesn't get a duplicate on this client stream.

-Jake

Geode Native Release

[Jacob Barrett]

All,

I want to start the discussion on releasing Geode Native C++ and .NET
clients with the next or near future Geode release.

There are a few house keeping items left in the source release JIRA [1]. It
would be great to get some help completing these tasks.

If we start with a source only release, which Geode release should we
target? Since it is "adding feature" it seems it makes the most sense to do
it as part of a minor release, say 1.2.

To throw a little wrench in it all. There are some serious changes coming
with [2] conversion to std::shared_ptr, [3] removal of all globals, [4]
replacing all non-standard concurrency methods. These changes won't be
compatible with sources written against previous releases of geode-native,
thus suggesting they will need a major rev shortly. My suggestion would be
to cut a release branch now on geode-native for 1.2 and get it ready for
source release. Backport any changes on the release branch to develop. That
leaves develop open for marching forward with what would be a 2.0 set of
sources. Any release of Geode 1.x would just include the geode-native
release/1.x branches until Geode 2.0.

Thoughts and feedback?

[1] https://issues.apache.org/jira/browse/GEODE-1416
[2] https://issues.apache.org/jira/browse/GEODE-2807
[3] https://issues.apache.org/jira/browse/GEODE-2729
[4] https://issues.apache.org/jira/browse/GEODE-2493

-Jake

[jira] [Assigned] (GEODE-234) remove deprecated MirrorType class

[Avinash Dongre (JIRA)]

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

Avinash Dongre reassigned GEODE-234:


Assignee: Avinash Dongre

> remove deprecated MirrorType class
> --
>
> Key: GEODE-234
> URL: https://issues.apache.org/jira/browse/GEODE-234
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> All uses of MirrorType should be changed to use DataPolicy.REPLICATE.
> All apis that take it as a parameter or return it need to be deleted.
> The cache-9.0.xsd should also be changed to no longer have the "mirror-type" 
> region-attribute.



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

[jira] [Resolved] (GEODE-1190) Should the LuceneServiceProvider get API take a GemFireCache instead of a Cache?

[nabarun (JIRA)]

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

nabarun resolved GEODE-1190.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Should the LuceneServiceProvider get API take a GemFireCache instead of a 
> Cache?
> 
>
> Key: GEODE-1190
> URL: https://issues.apache.org/jira/browse/GEODE-1190
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
> Fix For: 1.2.0
>
>
> Should the LuceneServiceProvider get API take a GemFireCache instead of a 
> Cache?
> The {{LuceneServiceProvider get}} API takes a {{Cache}} like:
> {noformat}
> public static LuceneService get(Cache cache)
> {noformat}
> If I create a {{ClientCache}}, I can't pass that into this method.
> Code like this doesn't compile:
> {noformat}
> ClientCache cache = new ClientCacheFactory().create();
> LuceneService luceneService = LuceneServiceProvider.get(cache);
> {noformat}
> Instead I have to cast the {{ClientCache}} to a {{Cache}}, but that doesn't 
> seem right:
> {noformat}
> ClientCache clientCache = new ClientCacheFactory().create();
> LuceneService luceneService = LuceneServiceProvider.get((Cache) clientCache);
> {noformat}



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

[jira] [Resolved] (GEODE-1125) Number of region entries does not match with the expected number at the end of tests

[nabarun (JIRA)]

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

nabarun resolved GEODE-1125.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Number of region entries does not match with the expected number at the end 
> of tests
> 
>
> Key: GEODE-1125
> URL: https://issues.apache.org/jira/browse/GEODE-1125
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: nabarun
>Assignee: nabarun
> Fix For: 1.2.0
>
>
> {panel:title=Error Log} 
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase$$Lambda$31/1631119258.run 
> in VM 2 running on Host 10.118.33.165 with 8 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:440)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:382)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:318)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.validateRegionSizes(WANTestBase.java:4868)
>   at 
> com.gemstone.gemfire.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOperation_2_DUnitTest.recreatePRDoPutsAndValidateRegionSizes(ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java:501)
>   at 
> com.gemstone.gemfire.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOperation_2_DUnitTest.testParallelGatewaySender_SingleNode_UserPR_Destroy_RecreateRegion(ConcurrentParallelGatewaySenderOperation_2_DUnitTest.java:88)
>   at sun.reflect.GeneratedMethodAccessor397.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:65)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: java.lang.AssertionError: Event never occurred after 24 ms: 
> Expected region entries: 10 but actual entries: 20 present region keyset [0, 
> 10, 1, 11, 2, 12, 3, 13, 4, 14, 5, 15, 16, 6, 17, 7, 18, 8, 19, 9]
>   at org.junit.Assert.fail(Assert.java:88)
>   at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:119)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:3719)
>   at 
> com.gemstone.gemfire.internal.cache.wan.WANTestBase.lambda$validateRegionSizes$985416d8$1(WANTestBase.java:4868)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at hydra.MethExecutor.executeObject(MethExecutor.java:268)
>   at 
> com.gemstone.gemfire.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:84)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:323)
>   at sun.rmi.transport.Transport$1.run(Transport.java:200)
>   at sun.rmi.transport.Transport$1.run(Transport.java:197)
>   at