Re: Kafka Ingester

[William Markito]

Hey Ross

This sounds like a great idea and I'd recommend it to be yet another separate 
module, like the Spark connector for example. 

Kafka and Geode share many similar concepts but support different data 
structures so there could be many different use cases for such connector. 

Looking forward for a proposal or topics to discuss as you find them. 

I'm not familiar with Ignite's implementation so can't comment on that. 

Sent from my iPhone

> On Jun 2, 2016, at 1:06 PM, Ross Duncan  wrote:
> 
> Hello,
> 
> I came across the landing page for Geode contributions today, and I noticed
> one of the suggested ideas (no 6) was a Kafka ingester plugin.
> 
> 
> https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute
> 
> I dont know terribly much about geode yet, but was wondering if anyone had
> attempted this yet?
> 
> If not, is there any prior art for ingesters of other technologies that
> might be worth a look?
> 
> Also I notice Ignite has a Kafka module, seemingly for a similar purpose,
> built around their API. Could this be another useful starting point?
> 
> Thanks,
> Rosco

Re: Review Request 48095: GEODE-1468 client/server messaging can create large objects

[Hitesh Khamesra]

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


Ship it!




Ship It!

- Hitesh Khamesra


On May 31, 2016, 10:15 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48095/
> ---
> 
> (Updated May 31, 2016, 10:15 p.m.)
> 
> 
> Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-1468
> https://issues.apache.org/jira/browse/GEODE-1468
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> After a Message has been sent we invoke clear() on each Part contained by the 
> Message.  This was nulling out the "part" variable of the Part objects but if 
> one of these "parts" was a HeapDataOutputStream it might hold a list of large 
> buffers.  This change set alters Part to close these streams so that their 
> buffers can be cleared.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/HeapDataOutputStream.java
>  20d01da880f2786a01ee4d4bd64681cd646acd31 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Message.java
>  a011875d4ea9aa9a14ac96e568fe6bba464bca89 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Part.java
>  bf90fab4999ce96adced9574678605d2bf8a903a 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/MessageJUnitTest.java
>  9f05aa7a0ae0d433ff9675a5fbcffc9c98ce8e7b 
> 
> Diff: https://reviews.apache.org/r/48095/diff/
> 
> 
> Testing
> ---
> 
> New test, precheckin
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: build error with development branch...

[Anilkumar Gingade]

Devs, Thanks for the help and pointers...

-Anil.


On Thu, Jun 2, 2016 at 2:49 PM, Udo Kohlmeyer  wrote:

> Maybe try 1.8.0_92... I know it works
>
>
> On 3/06/2016 7:47 am, Dan Smith wrote:
>
>> Hmm, does that -ea mean it's an early access build? I would recommend
>> running with a later version of java 8.
>>
>> -Dan
>>
>> On Thu, Jun 2, 2016 at 2:41 PM, Anilkumar Gingade 
>> wrote:
>>
>> If gradle is using the java installed/set in my environment, then it is:
>>>
>>> java version "1.8.0_20-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)
>>>
>>> I could not see any build output that printed java version it used (nice
>>> to
>>> have, if its not there)...
>>>
>>> -Anil.
>>>
>>>
>>>
>>> On Thu, Jun 2, 2016 at 2:14 PM, Dan Smith  wrote:
>>>
>>> Develop builds for me. And travis seems happy -
 https://travis-ci.org/apache/incubator-geode

 But this is actually pretty weird. In Intellij at least, it thinks that
 lambda maps to a SerializableCallable even though it doesn't return a
 value. I think maybe that's due to the while(true) part. If I comment

>>> that
>>>
 out, it maps to a runnable. It seems like this particular lambda
 actually
 *is* ambiguous since it will never return normally, it could be either a
 callable or a runnable.

 What JDK and what revision are you building with? Maybe some newer JDK
 is
 complaining about this?

 -Dan

 -Dan

 On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade 
 wrote:

 Hi Devs,
>
> Anyone seeing this issue:
>
>
>
>
>>> :geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
>>>
 error: reference to invokeAsync is ambiguous
>
>  AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader",
>
 ()
>>>
 ->

> {
>
> ^
>
>both method invokeAsync(String,SerializableRunnableIF) in VM and
>
 method
>>>
 invokeAsync(String,SerializableCallableIF) in VM match
>
>where T is a type-variable:
>
>  T extends Object declared in method
> invokeAsync(String,SerializableCallableIF)
>
>
>
>
>>> /export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
>>>
 warning: LdapCtxFactory is internal proprietary API and may be removed
>
 in a

> future release
>
>  env.put(Context.INITIAL_CONTEXT_FACTORY,
> com.sun.jndi.ldap.LdapCtxFactory.class.getName());
>
>^
>
> Note: 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.
>
> 1 error
>
>
> -Anil.
>
>
>

Re: Review Request 47686: GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).

[anilkumar gingade]

> On May 24, 2016, 9:44 p.m., Dan Smith wrote:
> > geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/StringQueryProvider.java,
> >  line 70
> > 
> >
> > The javadocs for setAllowLeadingWildercard say this: "Note that this 
> > can produce very slow queries on big indexes."
> > 
> > Is this something we really want to enable?

This is a very useful option to fetch all the data from the lucene index...In 
database its common to use "select all"...It could be expensive based on the 
index data size, as this is similar to table scanI could not find any place 
saying this will impact other queries...If you don't see need of this, I am 
fine with  removing this...


- anilkumar


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


On May 24, 2016, 12:05 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47686/
> ---
> 
> (Updated May 24, 2016, 12:05 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to 
> eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).  
> 
> Added test to verify, the lucene index gets updated with expiration destroy 
> operation.   
> Also added support to specify wild-char as leading wild character with Lucene 
> Query.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  d22ca4a196df3b1a457b56c92da694bdbf792cc2 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/StringQueryProvider.java
>  1e2b63d0fc5c7fad79063199c473bbd9d4e6fd00 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
>  07780ca06a297851c8ff4cb498a09f726a0785d5 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesIntegrationTest.java
>  15f5747231097df5223d97bb49110229efe6a824 
> 
> Diff: https://reviews.apache.org/r/47686/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Review Request 48188: GEODE-1495: Changes are made to remove the cached destroyed token/events from the CQ.

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
Jason Huynh, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

The CQEvents as seen by CQs are cached in order to avoid applying CQ queries on 
old values.

In case of a destory CQEvent, the CQEvents are marked with destroy tokens and 
removed from
the cache after the CQEvent is added to HAQueue.
This works fine for the CQs registered locally, but for the CQs registered on 
peer server, the
CQs weren't removed from the cache, which resulted in generating wrong CQEvent 
for subsequent
operation.
This change removes the destroy CQevent from the cache after the CQEvent is 
distributed to
peer server.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java
 6a7b4f2 

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


Testing
---

Reproduce the issue with manual testing. The test passed after the changes are 
made to remove cached destroy events from remote CQs.


Thanks,

anilkumar gingade

Re: Review Request 48187: GEODE-1491 A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back

[Eric Shu]

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

(Updated June 3, 2016, 12:05 a.m.)


Review request for geode, Darrel Schneider and Swapnil Bawaskar.


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


Repository: geode


Description
---

Make sure when checking if a transaction is completed from 
isHostedTxRecentlyCompleted() method, the rolled back transaction is considered 
as well.
Added a unit test that would fail without the fix and pass with the fix.


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java 
df0176d 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/PartitionMessage.java
 9c54587 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/RollbackCommand.java
 ed7c706 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/cache/TXManagerImplTest.java
 a4b8127 

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


Testing
---

precheckin.


Thanks,

Eric Shu

Re: Review Request 48187: GEODE-1491 A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back

[Darrel Schneider]

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




geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java 
(line 1024)


failoverMap is synchronized but this code does not look threadsafe. Between 
the call of "containsKey" and "remove" another thread might do a remove of a 
non-null value but has not yet put it back in. Then this thread does its remove 
and sees it return null and does a put of null.

I think you should bracket your containsKey, remove, and put calls with:
synchronized (failoverMap) {
}



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java 
(line 1028)


The comment talks about moving the txid to the front of the queue.
I would add that is does this by removing and putting the txid back into 
the Linked map.


- Darrel Schneider


On June 2, 2016, 2:33 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48187/
> ---
> 
> (Updated June 2, 2016, 2:33 p.m.)
> 
> 
> Review request for geode, Darrel Schneider and Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-1491
> https://issues.apache.org/jira/browse/GEODE-1491
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Make sure when checking if a transaction is completed from 
> isHostedTxRecentlyCompleted() method, the rolled back transaction is 
> considered as well.
> Added a unit test that would fail without the fix and pass with the fix.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java
>  df0176d 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/PartitionMessage.java
>  9c54587 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/RollbackCommand.java
>  ed7c706 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/TXManagerImplTest.java
>  a4b8127 
> 
> Diff: https://reviews.apache.org/r/48187/diff/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 48175: GEODE-1408: gfsh help alter region output defaults say '__DEFAULT__'

[Dave Barnes]

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


Ship it!




I believe that the code is correct - it appears to fix the six instances listed 
in the ticket (JIRA-1408).

The 6 targets were:
 - entry-idle-time-expiration-action
 - entry-time-to-live-expiration-action
 - region-idle-time-expiration-action
 - region-time-to-live-expiration-action
 - cache-loader
 - cache-writer

But for the record, the descriptive review text labeled "Here is the new help 
output" mistakenly shows a change for cache-listener, which in fact was made 
(correctly) in the code to cache-writer.

- Dave Barnes


On June 2, 2016, 5:05 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48175/
> ---
> 
> (Updated June 2, 2016, 5:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Karen Miller, Kevin Duling, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1408: gfsh help alter region output defaults say '__DEFAULT__'
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  d27786f72f039448b23af97408061cdd87295bfc 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
>  3c0d388d5af2c72864032d9ff0b469ddb4ff4393 
> 
> Diff: https://reviews.apache.org/r/48175/diff/
> 
> 
> Testing
> ---
> 
> Here is the new help output:
> 
> NAME
> alter region
> IS AVAILABLE
> false
> SYNOPSIS
> Alter a region with the given path and configuration.
> SYNTAX
> alter region --name=value [--group=value(,value)*] 
> [--entry-idle-time-expiration(=value)?] 
> [--entry-idle-time-expiration-action(=value)?] 
> [--entry-time-to-live-expiration(=value)?] 
> [--entry-time-to-live-expiration-action(=value)?]
> [--region-idle-time-expiration(=value)?] 
> [--region-idle-time-expiration-action(=value)?] 
> [--region-time-to-live-expiration(=value)?] 
> [--region-time-to-live-expiration-action(=value)?] 
> [--cache-listener=value(,value)*] [--cache-loader=value]
> [--cache-writer=value] [--async-event-queue-id=value(,value)*] 
> [--gateway-sender-id=value(,value)*] [--enable-cloning(=value)?] 
> [--eviction-max(=value)?]
> PARAMETERS
> name
> Name/Path of the region to be altered.
> Required: true
> group
> Group(s) of members on which the region will be altered.
> Required: false
> entry-idle-time-expiration
> How long the region's entries can remain in the cache without being 
> accessed. The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> entry-idle-time-expiration-action
> Action to be taken on an entry that has exceeded the idle expiration.
> Required: false
> Default (if the parameter is specified without value): INVALIDATE
> -->>   ^^ 
> new value
> entry-time-to-live-expiration
> How long the region's entries can remain in the cache without being 
> accessed or updated. The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> entry-time-to-live-expiration-action
> Action to be taken on an entry that has exceeded the TTL expiration.
> Required: false
> Default (if the parameter is specified without value): INVALIDATE
> -->>   ^^ 
> new value
> region-idle-time-expiration
> How long the region can remain in the cache without being accessed. 
> The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> region-idle-time-expiration-action
> Action to be taken on a region that has exceeded the idle expiration.
> Required: false
> Default (if the parameter is specified without value): INVALIDATE
> -->>   ^^ 
> new value
> region-time-to-live-expiration
> How long the region can remain in the cache without being accessed or 
> updated. The default is no expiration of this type.
> Required: false
> Default (if the parameter is specified without value): -1
> region-time-to-live-expiration-action
> Action to be taken on a region that has exceeded the TTL expiration.
> Required: false
> Default (if the parameter is specified 

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #328 was successful.
---
Scheduled
1400 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 48187: GEODE-1491 A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back

[Swapnil Bawaskar]

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


Ship it!




Ship It!

- Swapnil Bawaskar


On June 2, 2016, 9:33 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48187/
> ---
> 
> (Updated June 2, 2016, 9:33 p.m.)
> 
> 
> Review request for geode, Darrel Schneider and Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-1491
> https://issues.apache.org/jira/browse/GEODE-1491
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Make sure when checking if a transaction is completed from 
> isHostedTxRecentlyCompleted() method, the rolled back transaction is 
> considered as well.
> Added a unit test that would fail without the fix and pass with the fix.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java
>  df0176d 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/PartitionMessage.java
>  9c54587 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/RollbackCommand.java
>  ed7c706 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/TXManagerImplTest.java
>  a4b8127 
> 
> Diff: https://reviews.apache.org/r/48187/diff/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 47793: GEODE-93: Entry count stats are incorrect with PR with entry eviction and async disk

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On June 2, 2016, 2:26 p.m., Sai Boorlagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47793/
> ---
> 
> (Updated June 2, 2016, 2:26 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, Scott Jewell, and Ken 
> Howe.
> 
> 
> Bugs: GEODE-93
> https://issues.apache.org/jira/browse/GEODE-93
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Stats are not updated when a tombstone is scheduled/unscheduled.
> - All stats are updated when the data is finally flushed to the disk rather 
> than doing it eagerly and compensating when on a new operation if the data is 
> not yet written to disk
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DiskEntry.java 
> e015460ee412644b3bc62beb71403b9bd299ca48 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
> 8295487ef9e8930a929dfe8a10396bc83755ddc1 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/PartitionedRegionStatsJUnitTest.java
>  1a3277ca7b9597327e9ce42a61976ad731cc7c1c 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderQueueOverflowDUnitTest.java
>  7169b2e64071511e4732321882490e9b0b769025 
> 
> Diff: https://reviews.apache.org/r/47793/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Sai Boorlagadda
> 
>

Review Request 48189: remove sqlf, sql fabric, gemfirexd from geode-core

[Darrel Schneider]

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

Review request for geode, Eric Shu, Scott Jewell, Ken Howe, and Sai Boorlagadda.


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


Repository: geode


Description
---

removed internal Delta (only used by sqlf)
removed sqlfDisconnectListener
removed getStringForSQLF
removed sqlfabric.sys-disk-dir system property
removed unInitializedMembers and deferredVolunteerForPrimary
removed sqlf serialization code
removed GemFireUtilLauncher
removed afterValueOverflow
removed preferObject, eager deserialize, and KeyWithRegionContext
removed unused sqlf methods in PartitionedRegion
removed memberUnInitialized
removed sqlf from DiskEntry
removed setCallbackArgument from EntryOperationImpl
removed distributeUpdatedProfileOnHubCreation
removed getEntriesInTxForSqlFabric
removed withRoutingObjects and hasRoutingObjects
removed resetBucketAdvisorParents
rebalance no longer calls GemFireCacheImpl.getInstance comments
removed sqlf log messages
removed sqlf OffHeapIdentifiers
removed SqlfSerializationException from sanctionedSerializables
removed static helper methods from DiskWriteAttributesImpl
removed contextObject from EntryEventImpl
remove serializeCallbackArg from WrappedCallbackArgument since it was always 
true
removed getLeaderRegionName and getColocatedRegionName
removed newPutEntryEvent
removed clearLocalPrimaries
removed call to non-existent OSProcess$NativeOSCalls
removed putDML
removed getClassesToSerializers
simplified cleanUpOnImcompleteOp


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/IndexUpdater.java
 facbdf2cecd699361c3cc7782a38ab21d436637e 
  
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionMessage.java
 bb36b8023b050f17e2d8e742875c736bcabf7755 
  
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/InternalDistributedSystem.java
 552dbe3e2aeda91a6dbce7d0f27e07c038f683cc 
  
geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ReplyProcessor21.java
 e5e8cbfb9ab734d93fea991b1d6715b9a7b31a9e 
  geode-core/src/main/java/com/gemstone/gemfire/internal/DSCODE.java 
8d91c6b7e616e42f0c92da07492c2ade4d8e3e6f 
  geode-core/src/main/java/com/gemstone/gemfire/internal/DSFIDFactory.java 
bd78f5ae78953fab616f2ada870aa1aa920d56f3 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/DataSerializableFixedID.java
 7427f9009dfb732971970a518a2a27adc81c62cd 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/GemFireUtilLauncher.java 
fa19049a8f2e1af70250a7c18abe3d4fa8d27a26 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/InternalDataSerializer.java
 bff592b5ac8dc98f7bcd716910ae4c776fadb358 
  geode-core/src/main/java/com/gemstone/gemfire/internal/SystemAdmin.java 
515b27dcf0ff38ea5f1024f7ba8b7262172c203a 
  geode-core/src/main/java/com/gemstone/gemfire/internal/Version.java 
258eaf0e683da7ce4025f5cf388574935dcc3bc4 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/VersionedDataStream.java 
a2711ffee9e7575edeff8cd921a3168883ce9ec8 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractDiskRegionEntry.java
 b65b7addc4d572b262b0a0a8a99ee4a79ac0390f 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionEntry.java
 25cc818603e5a4f1a0a10f57a2861afb0599bd81 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionMap.java
 0cbec19408198a5d4fc7f975b43ad4075e29a580 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketAdvisor.java 
c241c6b7760e0cde59facd7f708c716f563eb2a9 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java 
e2482bb5592546d280c6f3fb73f7775e9a174afd 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/CacheDistributionAdvisor.java
 4a34771388da63a648c6d7763fc39334aa716b38 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/CacheServerLauncher.java
 d4c19ce6e0d464e90fd62935e00e7a7be72ce659 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/CachedDeserializableFactory.java
 84e44d84807ae05440edd664d1a4b0ab79bf9ea0 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ColocationHelper.java
 72edc1076c5480a665bba39af21ee87da7635372 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DestroyOperation.java
 e26719076eb0c49ae364da951f72fef7bf136a42 
  geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DiskEntry.java 
54ecb0434298ab6af2af8724a33048732735fc7d 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DiskInitFile.java 
7e2333e779db4a46d0fe1f88d7ae61c7831fde5a 
  geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DiskRegion.java 
c1d2f038992680e94cc5605ade0ae11bb3796531 
  

Re: build error with development branch...

[Udo Kohlmeyer]

Maybe try 1.8.0_92... I know it works


On 3/06/2016 7:47 am, Dan Smith wrote:

Hmm, does that -ea mean it's an early access build? I would recommend
running with a later version of java 8.

-Dan

On Thu, Jun 2, 2016 at 2:41 PM, Anilkumar Gingade 
wrote:


If gradle is using the java installed/set in my environment, then it is:

java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)

I could not see any build output that printed java version it used (nice to
have, if its not there)...

-Anil.



On Thu, Jun 2, 2016 at 2:14 PM, Dan Smith  wrote:


Develop builds for me. And travis seems happy -
https://travis-ci.org/apache/incubator-geode

But this is actually pretty weird. In Intellij at least, it thinks that
lambda maps to a SerializableCallable even though it doesn't return a
value. I think maybe that's due to the while(true) part. If I comment

that

out, it maps to a runnable. It seems like this particular lambda actually
*is* ambiguous since it will never return normally, it could be either a
callable or a runnable.

What JDK and what revision are you building with? Maybe some newer JDK is
complaining about this?

-Dan

-Dan

On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade 
wrote:


Hi Devs,

Anyone seeing this issue:




:geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:

error: reference to invokeAsync is ambiguous

 AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader",

()

->

{

^

   both method invokeAsync(String,SerializableRunnableIF) in VM and

method

invokeAsync(String,SerializableCallableIF) in VM match

   where T is a type-variable:

 T extends Object declared in method
invokeAsync(String,SerializableCallableIF)




/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:

warning: LdapCtxFactory is internal proprietary API and may be removed

in a

future release

 env.put(Context.INITIAL_CONTEXT_FACTORY,
com.sun.jndi.ldap.LdapCtxFactory.class.getName());

   ^

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

1 error


-Anil.

Re: build error with development branch...

[Anilkumar Gingade]

If gradle is using the java installed/set in my environment, then it is:

java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)

I could not see any build output that printed java version it used (nice to
have, if its not there)...

-Anil.



On Thu, Jun 2, 2016 at 2:14 PM, Dan Smith  wrote:

> Develop builds for me. And travis seems happy -
> https://travis-ci.org/apache/incubator-geode
>
> But this is actually pretty weird. In Intellij at least, it thinks that
> lambda maps to a SerializableCallable even though it doesn't return a
> value. I think maybe that's due to the while(true) part. If I comment that
> out, it maps to a runnable. It seems like this particular lambda actually
> *is* ambiguous since it will never return normally, it could be either a
> callable or a runnable.
>
> What JDK and what revision are you building with? Maybe some newer JDK is
> complaining about this?
>
> -Dan
>
> -Dan
>
> On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade 
> wrote:
>
> > Hi Devs,
> >
> > Anyone seeing this issue:
> >
> >
> >
> :geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
> > error: reference to invokeAsync is ambiguous
> >
> > AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", ()
> ->
> > {
> >
> >^
> >
> >   both method invokeAsync(String,SerializableRunnableIF) in VM and method
> > invokeAsync(String,SerializableCallableIF) in VM match
> >
> >   where T is a type-variable:
> >
> > T extends Object declared in method
> > invokeAsync(String,SerializableCallableIF)
> >
> >
> >
> /export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
> > warning: LdapCtxFactory is internal proprietary API and may be removed
> in a
> > future release
> >
> > env.put(Context.INITIAL_CONTEXT_FACTORY,
> > com.sun.jndi.ldap.LdapCtxFactory.class.getName());
> >
> >   ^
> >
> > Note: 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.
> >
> > 1 error
> >
> >
> > -Anil.
> >
>

Review Request 48187: GEODE-1491 A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back

[Eric Shu]

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

Review request for geode, Darrel Schneider and Swapnil Bawaskar.


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


Repository: geode


Description
---

Make sure when checking if a transaction is completed from 
isHostedTxRecentlyCompleted() method, the rolled back transaction is considered 
as well.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java 
df0176d 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/PartitionMessage.java
 9c54587 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/RollbackCommand.java
 ed7c706 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/cache/TXManagerImplTest.java
 a4b8127 

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


Testing
---

precheckin.


Thanks,

Eric Shu

Re: Review Request 48187: GEODE-1491 A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back

[Eric Shu]

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

(Updated June 2, 2016, 9:33 p.m.)


Review request for geode, Darrel Schneider and Swapnil Bawaskar.


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


Repository: geode


Description (updated)
---

Make sure when checking if a transaction is completed from 
isHostedTxRecentlyCompleted() method, the rolled back transaction is considered 
as well.
Added a unit test that would fail without the fix and pass with the fix.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/TXManagerImpl.java 
df0176d 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/PartitionMessage.java
 9c54587 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/RollbackCommand.java
 ed7c706 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/cache/TXManagerImplTest.java
 a4b8127 

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


Testing
---

precheckin.


Thanks,

Eric Shu

Re: Proposal - provide a callback to compute statistics

[Dan Smith]

On Thu, Jun 2, 2016 at 11:47 AM, Darrel Schneider 
wrote:

> Statistics are supposed to work even if you don't have sampling enabled.
> For example you could turn off sampling and not have a statistic archive
> but could still run a gfsh command that fetches a bunch of stats from the
> running system or use the pulse tool.
>
> However you can leave sampling turned on even if you do not have a
> statistic archive and it is true that our current OSStats (linux, windows,
> solaris) and VMStats are only updated when sampling is enabled.
> If you go with that then you just need to make clear that your sampler will
> only be called if the config property "statistic-sampling-enabled" is true
> and the frequency of calls will be determined by the config property
> "statistic-sample-rate".
>

Interesting. I think it make sense for these stats to be controlled by the
statistic-sampling-enabled property. It looks like that property defaults
to true, and the javadocs say that if you turn it off some of your stats
will display as 0.

-Dan

Re: Review Request 47793: GEODE-93: Entry count stats are incorrect with PR with entry eviction and async disk

[Sai Boorlagadda]

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

(Updated June 2, 2016, 9:26 p.m.)


Review request for geode, Darrel Schneider, Eric Shu, Scott Jewell, and Ken 
Howe.


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


Repository: geode


Description
---

- Stats are not updated when a tombstone is scheduled/unscheduled.
- All stats are updated when the data is finally flushed to the disk rather 
than doing it eagerly and compensating when on a new operation if the data is 
not yet written to disk


Diffs (updated)
-

  geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DiskEntry.java 
e015460ee412644b3bc62beb71403b9bd299ca48 
  geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
8295487ef9e8930a929dfe8a10396bc83755ddc1 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/cache/PartitionedRegionStatsJUnitTest.java
 1a3277ca7b9597327e9ce42a61976ad731cc7c1c 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderQueueOverflowDUnitTest.java
 7169b2e64071511e4732321882490e9b0b769025 

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


Testing
---

precheckin


Thanks,

Sai Boorlagadda

Re: Proposal - provide a callback to compute statistics

[Dan Smith]

On Thu, Jun 2, 2016 at 11:23 AM, Jens Deppe  wrote:

> If the methods are providing a Supplier (to the Statistic) shouldn't they
> be called 'set{Int,Long,Double}Supplier'?
>

Seems reasonable. I'll change them to be set{Int,Long,Double}Supplier

Re: build error with development branch...

[Dan Smith]

Develop builds for me. And travis seems happy -
https://travis-ci.org/apache/incubator-geode

But this is actually pretty weird. In Intellij at least, it thinks that
lambda maps to a SerializableCallable even though it doesn't return a
value. I think maybe that's due to the while(true) part. If I comment that
out, it maps to a runnable. It seems like this particular lambda actually
*is* ambiguous since it will never return normally, it could be either a
callable or a runnable.

What JDK and what revision are you building with? Maybe some newer JDK is
complaining about this?

-Dan

-Dan

On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade 
wrote:

> Hi Devs,
>
> Anyone seeing this issue:
>
>
> :geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
> error: reference to invokeAsync is ambiguous
>
> AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", () ->
> {
>
>^
>
>   both method invokeAsync(String,SerializableRunnableIF) in VM and method
> invokeAsync(String,SerializableCallableIF) in VM match
>
>   where T is a type-variable:
>
> T extends Object declared in method
> invokeAsync(String,SerializableCallableIF)
>
>
> /export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
> warning: LdapCtxFactory is internal proprietary API and may be removed in a
> future release
>
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> com.sun.jndi.ldap.LdapCtxFactory.class.getName());
>
>   ^
>
> Note: 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.
>
> 1 error
>
>
> -Anil.
>

Re: build error with development branch...

[Jinmei Liao]

Hmmm, never see that before. which version of java are you using?

On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade 
wrote:

> Hi Devs,
>
> Anyone seeing this issue:
>
>
> :geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
> error: reference to invokeAsync is ambiguous
>
> AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", () ->
> {
>
>^
>
>   both method invokeAsync(String,SerializableRunnableIF) in VM and method
> invokeAsync(String,SerializableCallableIF) in VM match
>
>   where T is a type-variable:
>
> T extends Object declared in method
> invokeAsync(String,SerializableCallableIF)
>
>
> /export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
> warning: LdapCtxFactory is internal proprietary API and may be removed in a
> future release
>
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> com.sun.jndi.ldap.LdapCtxFactory.class.getName());
>
>   ^
>
> Note: 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.
>
> 1 error
>
>
> -Anil.
>



-- 
Cheers

Jinmei

Re: build error with development branch...

[Udo Kohlmeyer]

I think that you getting this because vm1.invokeAsync(... seems to need 
to return something but it does not.


Maybe remove the 'AsynInvocation vm1Invoke =' part... As it serves no 
purpose here.


--Udo

On 3/06/2016 6:58 am, Anilkumar Gingade wrote:

Hi Devs,

Anyone seeing this issue:

:geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
error: reference to invokeAsync is ambiguous

 AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", () ->
{

^

   both method invokeAsync(String,SerializableRunnableIF) in VM and method
invokeAsync(String,SerializableCallableIF) in VM match

   where T is a type-variable:

 T extends Object declared in method
invokeAsync(String,SerializableCallableIF)

/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
warning: LdapCtxFactory is internal proprietary API and may be removed in a
future release

 env.put(Context.INITIAL_CONTEXT_FACTORY,
com.sun.jndi.ldap.LdapCtxFactory.class.getName());

   ^

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

1 error


-Anil.

build error with development branch...

[Anilkumar Gingade]

Hi Devs,

Anyone seeing this issue:

:geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
error: reference to invokeAsync is ambiguous

AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", () ->
{

   ^

  both method invokeAsync(String,SerializableRunnableIF) in VM and method
invokeAsync(String,SerializableCallableIF) in VM match

  where T is a type-variable:

T extends Object declared in method
invokeAsync(String,SerializableCallableIF)

/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
warning: LdapCtxFactory is internal proprietary API and may be removed in a
future release

env.put(Context.INITIAL_CONTEXT_FACTORY,
com.sun.jndi.ldap.LdapCtxFactory.class.getName());

  ^

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

1 error


-Anil.

Re: DistributionConfig and Geode system properties

[William Markito]

++1   - This is really good!

On Thu, Jun 2, 2016 at 12:16 PM, Udo Kohlmeyer 
wrote:

> John: Perhaps the (interface) name can be simplified to
> ConfigurationProperties too.
>
> Funnily enough I initially had called it SystemConfigurationProperties,
> but later renamed it because it felt too generic.
>
> Dan: 3) DistributedSystem has a ton of javadocs describing each property
> and what it does. I wonder if those javadocs should move to the constants
> in this interface instead?
>
> +1, Currently the Javadoc links back to the DistributedSystem javadoc,
> also happy to move that.
>
> DAN: 1) Is the idea with the change that all code should reference the
> constants in DistributedSystemConfigProperties. For example, I should use
> DistributedSystemConfigProperties.CACHE_XML_FILE when writing a test,
> rather than DistributionConfig.CACHE_XML_FILE? In that case, maybe
> DistributionConfig should not extend DistributedSystemConfigProperties?
>
> Correct, when referencing CACHE_XML_FILE, it should come from DSCP. The
> refactor started with the implementation of the interface, but we should
> cut the ties. Also with the current refactor I've tried to do minimally
> invasive surgery.
> Step1: was to extract all the properties into a single location and
> *hopefully* fix all code referencing it.
> Step2: Investigate the possibility to move/refactor the attribute
> configuration logic (attr type,min,max,default). Currently none of that
> information is directly linked to the DSCP properties.
>
> Bruce: Also, CacheFactory has two methods that should point to this new
> class:  CacheFactory(Properties) and set(String,String).
>
> Good point, we should change those links. I cannot help other than to ask
> the question, should the ConfigurationProperties not be an Enum? Then the
> */set(String,Sting)/* could become /*set(ConfigurationProperty,String)
> */which could make it even easier to configure the system when using the
> API. If we were to use the enum, we could set up (type,min,max,default) in
> a single location for consumption and documentation.
>
> --Udo
>
>
> On 3/06/2016 4:34 am, Darrel Schneider wrote:
>
>> +1 to naming it "ConfigurationProperties"
>> +1 to moving the javadocs
>>
>>
>> On Thu, Jun 2, 2016 at 10:46 AM, John Blum  wrote:
>>
>> Perhaps the (interface) name can be simplified to ConfigurationProperties
>>> too.  Not all properties necessarily involve specifically the distributed
>>> system configuration, but rather the overall Geode system configuration
>>> (Cache, Management, HTTP Service(s), Clients, etc).
>>>
>>> On Thu, Jun 2, 2016 at 10:27 AM, Dan Smith  wrote:
>>>
>>> First off - nice job, these constants should have been available a
 long time ago!

 One question a couple of comments:

 1) Is the idea with the change that all code should reference the
 constants in DistributedSystemConfigProperties. For example, I should
 use DistributedSystemConfigProperties.CACHE_XML_FILE when writing a
 test, rather than DistributionConfig.CACHE_XML_FILE? In that case,
 maybe DistributionConfig should not extend
 DistributedSystemConfigProperties?

 2) Add @since Geode 1.0 to this interface, as well as some javadocs
 describing to users what's contained in this interface.

 3) DistributedSystem has a ton of javadocs describing each property
 and what it does. I wonder if those javadocs should move to the
 constants in this interface instead?

 -Dan


 On Wed, Jun 1, 2016 at 5:17 PM, Udo Kohlmeyer 
 wrote:

> Hi there,
>
> As per GEODE-1377 
>
 I've

> refactored DistributionConfig to extract all public system properties
>
 into a

> public DistributedSystemConfigProperties interface.
>
> With that refactor I've touched a significant amount of classed and I,
>
 in
>>>
 advance, apologize for the merging.
>
> I've have tried to find all references to all the properties that we
>
 use
>>>
 within Geode (be it main and test).
>
> For future development, if we are to use and system properties, that we
>
 use

> the provided definition for that property. That will help us to
>
 understand

> where the properties are used and will make it easier if we need to
>
 refactor

> anything in the future.
>
> I've also tried to find every reference to "gemfire." and replaced it
>
 with

> its defined counterpart. This should hopefully help us if we were to
>
 move
>>>
 away from property definitions like "gemfire.locators" to
>
 "geode.locators".

> If someone were to find that I had missed an obvious property to please
> refactor and resolve that issue.
>
> In addition to this effort I 

Fwd: Kafka Ingester

[Ross Duncan]

Hello,

I came across the landing page for Geode contributions today, and I noticed
one of the suggested ideas (no 6) was a Kafka ingester plugin.


https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute

I dont know terribly much about geode yet, but was wondering if anyone had
attempted this yet?

If not, is there any prior art for ingesters of other technologies that
might be worth a look?

Also I notice Ignite has a Kafka module, seemingly for a similar purpose,
built around their API. Could this be another useful starting point?

Thanks,
Rosco

Re: Review Request 48176: Changed cache xml property for spark tests to use new DistributionConfig property

[Udo Kohlmeyer]

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


Ship it!




Once CACHE_XML_FILE has referenced the correct 
DistributedSystemConfigProperties.

- Udo Kohlmeyer


On June 2, 2016, 5:07 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48176/
> ---
> 
> (Updated June 2, 2016, 5:07 p.m.)
> 
> 
> Review request for geode, William Markito, Udo Kohlmeyer, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The spark build is currently broken due to an invalid property
> 
> 
> Diffs
> -
> 
>   
> geode-spark-connector/geode-spark-connector/src/it/java/ittest/io/pivotal/geode/spark/connector/JavaApiIntegrationTest.java
>  1c6a5a2 
> 
> Diff: https://reviews.apache.org/r/48176/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 48176: Changed cache xml property for spark tests to use new DistributionConfig property

[Udo Kohlmeyer]

> On June 2, 2016, 5:16 p.m., Dan Smith wrote:
> > geode-spark-connector/geode-spark-connector/src/it/java/ittest/io/pivotal/geode/spark/connector/JavaApiIntegrationTest.java,
> >  line 62
> > 
> >
> > Should this use DistributedSystemConfigProperties.CACHE_XML_FILE 
> > instead?

Agreed, this should be DistributedSystemConfigProperties.CACHE_XML_FILE.


- Udo


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


On June 2, 2016, 5:07 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48176/
> ---
> 
> (Updated June 2, 2016, 5:07 p.m.)
> 
> 
> Review request for geode, William Markito, Udo Kohlmeyer, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The spark build is currently broken due to an invalid property
> 
> 
> Diffs
> -
> 
>   
> geode-spark-connector/geode-spark-connector/src/it/java/ittest/io/pivotal/geode/spark/connector/JavaApiIntegrationTest.java
>  1c6a5a2 
> 
> Diff: https://reviews.apache.org/r/48176/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: DistributionConfig and Geode system properties

[Udo Kohlmeyer]

John: Perhaps the (interface) name can be simplified to ConfigurationProperties 
too.

Funnily enough I initially had called it SystemConfigurationProperties, 
but later renamed it because it felt too generic.


Dan: 3) DistributedSystem has a ton of javadocs describing each property and 
what it does. I wonder if those javadocs should move to the constants in this 
interface instead?

+1, Currently the Javadoc links back to the DistributedSystem javadoc, 
also happy to move that.


DAN: 1) Is the idea with the change that all code should reference the 
constants in DistributedSystemConfigProperties. For example, I should use 
DistributedSystemConfigProperties.CACHE_XML_FILE when writing a test, rather 
than DistributionConfig.CACHE_XML_FILE? In that case, maybe DistributionConfig 
should not extend DistributedSystemConfigProperties?

Correct, when referencing CACHE_XML_FILE, it should come from DSCP. The 
refactor started with the implementation of the interface, but we should 
cut the ties. Also with the current refactor I've tried to do minimally 
invasive surgery.
Step1: was to extract all the properties into a single location and 
*hopefully* fix all code referencing it.
Step2: Investigate the possibility to move/refactor the attribute 
configuration logic (attr type,min,max,default). Currently none of that 
information is directly linked to the DSCP properties.


Bruce: Also, CacheFactory has two methods that should point to this new class:  
CacheFactory(Properties) and set(String,String).

Good point, we should change those links. I cannot help other than to 
ask the question, should the ConfigurationProperties not be an Enum? 
Then the */set(String,Sting)/* could become 
/*set(ConfigurationProperty,String) */which could make it even easier to 
configure the system when using the API. If we were to use the enum, we 
could set up (type,min,max,default) in a single location for consumption 
and documentation.


--Udo

On 3/06/2016 4:34 am, Darrel Schneider wrote:

+1 to naming it "ConfigurationProperties"
+1 to moving the javadocs


On Thu, Jun 2, 2016 at 10:46 AM, John Blum  wrote:


Perhaps the (interface) name can be simplified to ConfigurationProperties
too.  Not all properties necessarily involve specifically the distributed
system configuration, but rather the overall Geode system configuration
(Cache, Management, HTTP Service(s), Clients, etc).

On Thu, Jun 2, 2016 at 10:27 AM, Dan Smith  wrote:


First off - nice job, these constants should have been available a
long time ago!

One question a couple of comments:

1) Is the idea with the change that all code should reference the
constants in DistributedSystemConfigProperties. For example, I should
use DistributedSystemConfigProperties.CACHE_XML_FILE when writing a
test, rather than DistributionConfig.CACHE_XML_FILE? In that case,
maybe DistributionConfig should not extend
DistributedSystemConfigProperties?

2) Add @since Geode 1.0 to this interface, as well as some javadocs
describing to users what's contained in this interface.

3) DistributedSystem has a ton of javadocs describing each property
and what it does. I wonder if those javadocs should move to the
constants in this interface instead?

-Dan


On Wed, Jun 1, 2016 at 5:17 PM, Udo Kohlmeyer 
wrote:

Hi there,

As per GEODE-1377 

I've

refactored DistributionConfig to extract all public system properties

into a

public DistributedSystemConfigProperties interface.

With that refactor I've touched a significant amount of classed and I,

in

advance, apologize for the merging.

I've have tried to find all references to all the properties that we

use

within Geode (be it main and test).

For future development, if we are to use and system properties, that we

use

the provided definition for that property. That will help us to

understand

where the properties are used and will make it easier if we need to

refactor

anything in the future.

I've also tried to find every reference to "gemfire." and replaced it

with

its defined counterpart. This should hopefully help us if we were to

move

away from property definitions like "gemfire.locators" to

"geode.locators".

If someone were to find that I had missed an obvious property to please
refactor and resolve that issue.

In addition to this effort I have noticed that we use a large amount of
properties to configure functionality. I respectfully request from all
developers that if you were to work on some code that uses "internal"
properties to maybe pull it out into a common interface which can be

reused

throughout the code base.

--Udo





--
-John
503-504-8657
john.blum10101 (skype)

Re: Proposal - provide a callback to compute statistics

[Darrel Schneider]

Statistics are supposed to work even if you don't have sampling enabled.
For example you could turn off sampling and not have a statistic archive
but could still run a gfsh command that fetches a bunch of stats from the
running system or use the pulse tool.

However you can leave sampling turned on even if you do not have a
statistic archive and it is true that our current OSStats (linux, windows,
solaris) and VMStats are only updated when sampling is enabled.
If you go with that then you just need to make clear that your sampler will
only be called if the config property "statistic-sampling-enabled" is true
and the frequency of calls will be determined by the config property
"statistic-sample-rate".

On Thu, Jun 2, 2016 at 11:23 AM, Jens Deppe  wrote:

> If the methods are providing a Supplier (to the Statistic) shouldn't they
> be called 'set{Int,Long,Double}Supplier'?
>
> On Thu, Jun 2, 2016 at 11:04 AM, Dan Smith  wrote:
>
> > Replies inline.
> >
> > On Thu, Jun 2, 2016 at 10:04 AM, Darrel Schneider  >
> > wrote:
> >
> > > It is not clear to me how the new apis behave.
> > > Is the supplier for a particular id/name/descriptor remembered by the
> > > Statistics instance? So if you wanted to add an intSupplier for a int
> > > statistic you would do it once by calling sampleInt?
> > >
> >
> > Yeah, that's what I was going for. You install the supplier once and then
> > it gets called every sample.
> >
> >
> >
> > > The name of these methods give the impression that calling it will
> take a
> > > sample. Perhaps it should be setSampler? Do you need the type (int,
> long,
> > > etc) in the name or is overloading ok?
> > >
> >
> > I'll rename it to setSampler, that seems clearer. Name overloading should
> > work, but I was trying to be consistent with the existing methods. We
> have
> > incInt, intLong, incDouble. Should I follow a different pattern for these
> > setSampler methods?
> >
> >
> > > Does the supplier need to match the type of the stat otherwise you get
> > > IllegalArgumentException?
> > >
> >
> > That seems like a good idea, I'll clarify that in the javadocs.
> >
> >
> > > Can you only have one sampler registered for a particular stat? If so
> > > should these methods return the old one?
> > >
> >
> > Seems like a good idea. I was also thinking maybe for completeness if you
> > set the sampler to null it will remove it. I'll clarify the javadocs.
> >
> >
> > > How does a sampler interact with the existing methods on the same stat?
> > Do
> > > the "get" methods implicitly call the sampler to compute the result
> they
> > > return? If so then the "set" and "inc" methods become noops.
> > >
> > > I was thinking get would just return the last sampled value - it would
> > not
> > trigger an immediate recomputation. But it's true that set and inc are
> > basically useless if you have a supplier set.
> >
> > -Dan
> >
>

Re: DistributionConfig and Geode system properties

[Darrel Schneider]

+1 to naming it "ConfigurationProperties"
+1 to moving the javadocs


On Thu, Jun 2, 2016 at 10:46 AM, John Blum  wrote:

> Perhaps the (interface) name can be simplified to ConfigurationProperties
> too.  Not all properties necessarily involve specifically the distributed
> system configuration, but rather the overall Geode system configuration
> (Cache, Management, HTTP Service(s), Clients, etc).
>
> On Thu, Jun 2, 2016 at 10:27 AM, Dan Smith  wrote:
>
> > First off - nice job, these constants should have been available a
> > long time ago!
> >
> > One question a couple of comments:
> >
> > 1) Is the idea with the change that all code should reference the
> > constants in DistributedSystemConfigProperties. For example, I should
> > use DistributedSystemConfigProperties.CACHE_XML_FILE when writing a
> > test, rather than DistributionConfig.CACHE_XML_FILE? In that case,
> > maybe DistributionConfig should not extend
> > DistributedSystemConfigProperties?
> >
> > 2) Add @since Geode 1.0 to this interface, as well as some javadocs
> > describing to users what's contained in this interface.
> >
> > 3) DistributedSystem has a ton of javadocs describing each property
> > and what it does. I wonder if those javadocs should move to the
> > constants in this interface instead?
> >
> > -Dan
> >
> >
> > On Wed, Jun 1, 2016 at 5:17 PM, Udo Kohlmeyer 
> > wrote:
> > > Hi there,
> > >
> > > As per GEODE-1377 
> > I've
> > > refactored DistributionConfig to extract all public system properties
> > into a
> > > public DistributedSystemConfigProperties interface.
> > >
> > > With that refactor I've touched a significant amount of classed and I,
> in
> > > advance, apologize for the merging.
> > >
> > > I've have tried to find all references to all the properties that we
> use
> > > within Geode (be it main and test).
> > >
> > > For future development, if we are to use and system properties, that we
> > use
> > > the provided definition for that property. That will help us to
> > understand
> > > where the properties are used and will make it easier if we need to
> > refactor
> > > anything in the future.
> > >
> > > I've also tried to find every reference to "gemfire." and replaced it
> > with
> > > its defined counterpart. This should hopefully help us if we were to
> move
> > > away from property definitions like "gemfire.locators" to
> > "geode.locators".
> > > If someone were to find that I had missed an obvious property to please
> > > refactor and resolve that issue.
> > >
> > > In addition to this effort I have noticed that we use a large amount of
> > > properties to configure functionality. I respectfully request from all
> > > developers that if you were to work on some code that uses "internal"
> > > properties to maybe pull it out into a common interface which can be
> > reused
> > > throughout the code base.
> > >
> > > --Udo
> > >
> > >
> >
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Re: Proposal - provide a callback to compute statistics

[Jens Deppe]

If the methods are providing a Supplier (to the Statistic) shouldn't they
be called 'set{Int,Long,Double}Supplier'?

On Thu, Jun 2, 2016 at 11:04 AM, Dan Smith  wrote:

> Replies inline.
>
> On Thu, Jun 2, 2016 at 10:04 AM, Darrel Schneider 
> wrote:
>
> > It is not clear to me how the new apis behave.
> > Is the supplier for a particular id/name/descriptor remembered by the
> > Statistics instance? So if you wanted to add an intSupplier for a int
> > statistic you would do it once by calling sampleInt?
> >
>
> Yeah, that's what I was going for. You install the supplier once and then
> it gets called every sample.
>
>
>
> > The name of these methods give the impression that calling it will take a
> > sample. Perhaps it should be setSampler? Do you need the type (int, long,
> > etc) in the name or is overloading ok?
> >
>
> I'll rename it to setSampler, that seems clearer. Name overloading should
> work, but I was trying to be consistent with the existing methods. We have
> incInt, intLong, incDouble. Should I follow a different pattern for these
> setSampler methods?
>
>
> > Does the supplier need to match the type of the stat otherwise you get
> > IllegalArgumentException?
> >
>
> That seems like a good idea, I'll clarify that in the javadocs.
>
>
> > Can you only have one sampler registered for a particular stat? If so
> > should these methods return the old one?
> >
>
> Seems like a good idea. I was also thinking maybe for completeness if you
> set the sampler to null it will remove it. I'll clarify the javadocs.
>
>
> > How does a sampler interact with the existing methods on the same stat?
> Do
> > the "get" methods implicitly call the sampler to compute the result they
> > return? If so then the "set" and "inc" methods become noops.
> >
> > I was thinking get would just return the last sampled value - it would
> not
> trigger an immediate recomputation. But it's true that set and inc are
> basically useless if you have a supplier set.
>
> -Dan
>

Re: Proposal to allow eviction and expiration operations/events with AsyncEventQueue.

[Anilkumar Gingade]

Hi Team,

As proposed here, we added support to propagate eviction and expiration
(destroy) operation to AsyncEventQueue using single flag/attribute
"ignoreEvictionAndExpiration" by default which is true (to keep the same
behavior) and one could set (false) to receive eviction/expiration event...

But we come across a product issue, GEODE-1472, that cause data
inconsistency (with eviction destroy)For this reason we are planning to
break the "ignoreEvictionAndExpiration" attribute to eviction and
expiration specific:
"ignoreEvictionDestroy", "ignoreExpirationDestroy"...

Currently we are planning to support "ignoreExpirationDestroy",  and add
"ignoreEvictionDestroy" once GEODE-1472 is fixed...

Looking for comments on this...

Thanks,
-Anil.

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




On Tue, Apr 12, 2016 at 6:04 PM, Anilkumar Gingade 
wrote:

> Kirk, We could not think of any such requirement...And with this
> application will get all the update operation and can take appropriate
> action (use or ignore)...
>
> -Anil.
>
>
>
> On Tue, Apr 12, 2016 at 5:46 PM, Kirk Lund  wrote:
>
>> Would any user ever have a reason to enable forwarding of one type but not
>> the other? If so then I would separate them as forwardEvictionEvents() and
>> forwardExpirationEvents().
>>
>>
>> On Tue, Apr 12, 2016 at 5:44 PM, Kirk Lund  wrote:
>>
>> > +1 for being more explicit with the "And" conjunction
>> >
>> > -Kirk
>> >
>> >
>> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker 
>> wrote:
>> >
>> >> I’d prefer to insert a conjunction to clarify the meaning:
>> >>
>> >> forwardEvictionAndExpirationEvents()
>> >>
>> >>
>> >> $0.02,
>> >> Anthony
>> >>
>> >> On Apr 12, 2016, at 5:11 PM, Anilkumar Gingade 
>> >> wrote:
>> >>
>> >> *New attribute:* "forwardEvictionExpirationEvents()" (Any alternate
>> >> names?).
>> >>
>> >>
>> >>
>> >
>>
>
>

Re: Proposal - provide a callback to compute statistics

[Dan Smith]

Replies inline.

On Thu, Jun 2, 2016 at 10:04 AM, Darrel Schneider 
wrote:

> It is not clear to me how the new apis behave.
> Is the supplier for a particular id/name/descriptor remembered by the
> Statistics instance? So if you wanted to add an intSupplier for a int
> statistic you would do it once by calling sampleInt?
>

Yeah, that's what I was going for. You install the supplier once and then
it gets called every sample.



> The name of these methods give the impression that calling it will take a
> sample. Perhaps it should be setSampler? Do you need the type (int, long,
> etc) in the name or is overloading ok?
>

I'll rename it to setSampler, that seems clearer. Name overloading should
work, but I was trying to be consistent with the existing methods. We have
incInt, intLong, incDouble. Should I follow a different pattern for these
setSampler methods?


> Does the supplier need to match the type of the stat otherwise you get
> IllegalArgumentException?
>

That seems like a good idea, I'll clarify that in the javadocs.


> Can you only have one sampler registered for a particular stat? If so
> should these methods return the old one?
>

Seems like a good idea. I was also thinking maybe for completeness if you
set the sampler to null it will remove it. I'll clarify the javadocs.


> How does a sampler interact with the existing methods on the same stat? Do
> the "get" methods implicitly call the sampler to compute the result they
> return? If so then the "set" and "inc" methods become noops.
>
> I was thinking get would just return the last sampled value - it would not
trigger an immediate recomputation. But it's true that set and inc are
basically useless if you have a supplier set.

-Dan

Re: DistributionConfig and Geode system properties

[John Blum]

Perhaps the (interface) name can be simplified to ConfigurationProperties
too.  Not all properties necessarily involve specifically the distributed
system configuration, but rather the overall Geode system configuration
(Cache, Management, HTTP Service(s), Clients, etc).

On Thu, Jun 2, 2016 at 10:27 AM, Dan Smith  wrote:

> First off - nice job, these constants should have been available a
> long time ago!
>
> One question a couple of comments:
>
> 1) Is the idea with the change that all code should reference the
> constants in DistributedSystemConfigProperties. For example, I should
> use DistributedSystemConfigProperties.CACHE_XML_FILE when writing a
> test, rather than DistributionConfig.CACHE_XML_FILE? In that case,
> maybe DistributionConfig should not extend
> DistributedSystemConfigProperties?
>
> 2) Add @since Geode 1.0 to this interface, as well as some javadocs
> describing to users what's contained in this interface.
>
> 3) DistributedSystem has a ton of javadocs describing each property
> and what it does. I wonder if those javadocs should move to the
> constants in this interface instead?
>
> -Dan
>
>
> On Wed, Jun 1, 2016 at 5:17 PM, Udo Kohlmeyer 
> wrote:
> > Hi there,
> >
> > As per GEODE-1377 
> I've
> > refactored DistributionConfig to extract all public system properties
> into a
> > public DistributedSystemConfigProperties interface.
> >
> > With that refactor I've touched a significant amount of classed and I, in
> > advance, apologize for the merging.
> >
> > I've have tried to find all references to all the properties that we use
> > within Geode (be it main and test).
> >
> > For future development, if we are to use and system properties, that we
> use
> > the provided definition for that property. That will help us to
> understand
> > where the properties are used and will make it easier if we need to
> refactor
> > anything in the future.
> >
> > I've also tried to find every reference to "gemfire." and replaced it
> with
> > its defined counterpart. This should hopefully help us if we were to move
> > away from property definitions like "gemfire.locators" to
> "geode.locators".
> > If someone were to find that I had missed an obvious property to please
> > refactor and resolve that issue.
> >
> > In addition to this effort I have noticed that we use a large amount of
> > properties to configure functionality. I respectfully request from all
> > developers that if you were to work on some code that uses "internal"
> > properties to maybe pull it out into a common interface which can be
> reused
> > throughout the code base.
> >
> > --Udo
> >
> >
>



-- 
-John
503-504-8657
john.blum10101 (skype)

Re: DistributionConfig and Geode system properties

[Bruce Schuchardt]

+1 for moving the javadocs

Also, CacheFactory has two methods that should point to this new class:  
CacheFactory(Properties) and set(String,String).


Le 6/2/2016 à 10:27 AM, Dan Smith a écrit :

3) DistributedSystem has a ton of javadocs describing each property
and what it does. I wonder if those javadocs should move to the
constants in this interface instead?

-Dan

Re: DistributionConfig and Geode system properties

[Dan Smith]

First off - nice job, these constants should have been available a
long time ago!

One question a couple of comments:

1) Is the idea with the change that all code should reference the
constants in DistributedSystemConfigProperties. For example, I should
use DistributedSystemConfigProperties.CACHE_XML_FILE when writing a
test, rather than DistributionConfig.CACHE_XML_FILE? In that case,
maybe DistributionConfig should not extend
DistributedSystemConfigProperties?

2) Add @since Geode 1.0 to this interface, as well as some javadocs
describing to users what's contained in this interface.

3) DistributedSystem has a ton of javadocs describing each property
and what it does. I wonder if those javadocs should move to the
constants in this interface instead?

-Dan


On Wed, Jun 1, 2016 at 5:17 PM, Udo Kohlmeyer  wrote:
> Hi there,
>
> As per GEODE-1377  I've
> refactored DistributionConfig to extract all public system properties into a
> public DistributedSystemConfigProperties interface.
>
> With that refactor I've touched a significant amount of classed and I, in
> advance, apologize for the merging.
>
> I've have tried to find all references to all the properties that we use
> within Geode (be it main and test).
>
> For future development, if we are to use and system properties, that we use
> the provided definition for that property. That will help us to understand
> where the properties are used and will make it easier if we need to refactor
> anything in the future.
>
> I've also tried to find every reference to "gemfire." and replaced it with
> its defined counterpart. This should hopefully help us if we were to move
> away from property definitions like "gemfire.locators" to "geode.locators".
> If someone were to find that I had missed an obvious property to please
> refactor and resolve that issue.
>
> In addition to this effort I have noticed that we use a large amount of
> properties to configure functionality. I respectfully request from all
> developers that if you were to work on some code that uses "internal"
> properties to maybe pull it out into a common interface which can be reused
> throughout the code base.
>
> --Udo
>
>

Re: Review Request 48176: Changed cache xml property for spark tests to use new DistributionConfig property

[Dan Smith]

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


Fix it, then Ship it!




Ship It!


geode-spark-connector/geode-spark-connector/src/it/java/ittest/io/pivotal/geode/spark/connector/JavaApiIntegrationTest.java
 (line 61)


Should this use DistributedSystemConfigProperties.CACHE_XML_FILE instead?


- Dan Smith


On June 2, 2016, 5:07 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48176/
> ---
> 
> (Updated June 2, 2016, 5:07 p.m.)
> 
> 
> Review request for geode, William Markito, Udo Kohlmeyer, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The spark build is currently broken due to an invalid property
> 
> 
> Diffs
> -
> 
>   
> geode-spark-connector/geode-spark-connector/src/it/java/ittest/io/pivotal/geode/spark/connector/JavaApiIntegrationTest.java
>  1c6a5a2 
> 
> Diff: https://reviews.apache.org/r/48176/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Review Request 48176: Changed cache xml property for spark tests to use new DistributionConfig property

[Jason Huynh]

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

Review request for geode, William Markito, Udo Kohlmeyer, and Dan Smith.


Repository: geode


Description
---

The spark build is currently broken due to an invalid property


Diffs
-

  
geode-spark-connector/geode-spark-connector/src/it/java/ittest/io/pivotal/geode/spark/connector/JavaApiIntegrationTest.java
 1c6a5a2 

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


Testing
---


Thanks,

Jason Huynh

Review Request 48175: GEODE-1408: gfsh help alter region output defaults say '__DEFAULT__'

[Jens Deppe]

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

Review request for geode, Jinmei Liao, Karen Miller, Kevin Duling, and Kirk 
Lund.


Repository: geode


Description
---

GEODE-1408: gfsh help alter region output defaults say '__DEFAULT__'


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
 d27786f72f039448b23af97408061cdd87295bfc 
  
geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
 3c0d388d5af2c72864032d9ff0b469ddb4ff4393 

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


Testing
---

Here is the new help output:

NAME
alter region
IS AVAILABLE
false
SYNOPSIS
Alter a region with the given path and configuration.
SYNTAX
alter region --name=value [--group=value(,value)*] 
[--entry-idle-time-expiration(=value)?] 
[--entry-idle-time-expiration-action(=value)?] 
[--entry-time-to-live-expiration(=value)?] 
[--entry-time-to-live-expiration-action(=value)?]
[--region-idle-time-expiration(=value)?] 
[--region-idle-time-expiration-action(=value)?] 
[--region-time-to-live-expiration(=value)?] 
[--region-time-to-live-expiration-action(=value)?] 
[--cache-listener=value(,value)*] [--cache-loader=value]
[--cache-writer=value] [--async-event-queue-id=value(,value)*] 
[--gateway-sender-id=value(,value)*] [--enable-cloning(=value)?] 
[--eviction-max(=value)?]
PARAMETERS
name
Name/Path of the region to be altered.
Required: true
group
Group(s) of members on which the region will be altered.
Required: false
entry-idle-time-expiration
How long the region's entries can remain in the cache without being 
accessed. The default is no expiration of this type.
Required: false
Default (if the parameter is specified without value): -1
entry-idle-time-expiration-action
Action to be taken on an entry that has exceeded the idle expiration.
Required: false
Default (if the parameter is specified without value): INVALIDATE
-->>   ^^ 
new value
entry-time-to-live-expiration
How long the region's entries can remain in the cache without being 
accessed or updated. The default is no expiration of this type.
Required: false
Default (if the parameter is specified without value): -1
entry-time-to-live-expiration-action
Action to be taken on an entry that has exceeded the TTL expiration.
Required: false
Default (if the parameter is specified without value): INVALIDATE
-->>   ^^ 
new value
region-idle-time-expiration
How long the region can remain in the cache without being accessed. The 
default is no expiration of this type.
Required: false
Default (if the parameter is specified without value): -1
region-idle-time-expiration-action
Action to be taken on a region that has exceeded the idle expiration.
Required: false
Default (if the parameter is specified without value): INVALIDATE
-->>   ^^ 
new value
region-time-to-live-expiration
How long the region can remain in the cache without being accessed or 
updated. The default is no expiration of this type.
Required: false
Default (if the parameter is specified without value): -1
region-time-to-live-expiration-action
Action to be taken on a region that has exceeded the TTL expiration.
Required: false
Default (if the parameter is specified without value): INVALIDATE
-->>   ^^ 
new value
cache-listener
Fully qualified class name of a plug-in to be instantiated for 
receiving after-event notification of changes to the region and its entries. 
Any number of cache listeners can be configured.
Required: false
-->> No default value shown on this line
cache-loader
Fully qualified class name of a plug-in to be instantiated for 
receiving notification of cache misses in the region. At most, one cache loader 
can be defined in each member for the region. For distributed regions, a cache 
loader may be invoked remotely
from other members that have the region defined.
Required: false
-->> No default value shown on this line
cache-writer
Fully qualified class name of a plug-in to be instantiated for 
receiving before-event notification of changes to the region and its entries. 
The plug-in may cancel the event. At most, one cache writer can be defined in 
each member for the region.
 

Re: Proposal - provide a callback to compute statistics

[Darrel Schneider]

It is not clear to me how the new apis behave.
Is the supplier for a particular id/name/descriptor remembered by the
Statistics instance? So if you wanted to add an intSupplier for a int
statistic you would do it once by calling sampleInt?

The name of these methods give the impression that calling it will take a
sample. Perhaps it should be setSampler? Do you need the type (int, long,
etc) in the name or is overloading ok?
Does the supplier need to match the type of the stat otherwise you get
IllegalArgumentException?
Can you only have one sampler registered for a particular stat? If so
should these methods return the old one?
How does a sampler interact with the existing methods on the same stat? Do
the "get" methods implicitly call the sampler to compute the result they
return? If so then the "set" and "inc" methods become noops.



On Wed, Jun 1, 2016 at 4:33 PM, Dan Smith  wrote:

> I'm suggesting using standard Java 8 function interfaces for the
> callbacks - IntSupplier, DoubleSupplier, etc. I can change the name of
> the argument to supplier.
>
> -Dan
>
> On Wed, Jun 1, 2016 at 4:18 PM, Xiaojian Zhou  wrote:
> > what's the difference btw supplier and sampler?
> >
> > On Wed, Jun 1, 2016 at 4:12 PM, Dan Smith  wrote:
> >
> >> Hi,
> >>
> >> I'd like to add some new methods to the Statistics interface to compute
> >> statistics using callbacks. My original motivation for this is to make
> it
> >> easy to record statistics that come from lucene for our lucene
> integration,
> >> but I think this could simplify recording statistics in a lot of places.
> >>
> >> The basic idea is that the user provides a callback that returns the
> value
> >> of the statistic. Geode will call the callback every sample interval to
> >> recompute the value.
> >>
> >> See the JIRA for more details:
> >> https://issues.apache.org/jira/browse/GEODE-1494
> >>
> >> Thoughts?
> >>
> >> -Dan
> >>
>

Re: DistributionConfig and Geode system properties

[Anthony Baker]

Since this an addition to the public API (albeit small) please make sure to 
review and offer feedback.

We should consider how future changes (property additions, removals, renames, 
defaults) will impact backwards compatibility.

Thanks,
Anthony

> On Jun 1, 2016, at 5:17 PM, Udo Kohlmeyer  wrote:
> 
> Hi there,
> 
> As per GEODE-1377  I've 
> refactored DistributionConfig to extract all public system properties into a 
> public DistributedSystemConfigProperties interface.
> 
> With that refactor I've touched a significant amount of classed and I, in 
> advance, apologize for the merging.
> 
> I've have tried to find all references to all the properties that we use 
> within Geode (be it main and test).
> 
> For future development, if we are to use and system properties, that we use 
> the provided definition for that property. That will help us to understand 
> where the properties are used and will make it easier if we need to refactor 
> anything in the future.
> 
> I've also tried to find every reference to "gemfire." and replaced it with 
> its defined counterpart. This should hopefully help us if we were to move 
> away from property definitions like "gemfire.locators" to "geode.locators". 
> If someone were to find that I had missed an obvious property to please 
> refactor and resolve that issue.
> 
> In addition to this effort I have noticed that we use a large amount of 
> properties to configure functionality. I respectfully request from all 
> developers that if you were to work on some code that uses "internal" 
> properties to maybe pull it out into a common interface which can be reused 
> throughout the code base.
> 
> --Udo
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Review Request 47850: GEODE-1454: Have "region" attribute, in JSONAuthorization json file be an array

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On May 25, 2016, 8:27 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47850/
> ---
> 
> (Updated May 25, 2016, 8:27 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Also converted to Jackson. Be gone org.json!!
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/JSONAuthorization.java
>  e14d1def97a06e479cbeeffe56a05e8e8de16d65 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/security/cacheServer.json
>  fbbda8d0369bd7fdf400ba226c67d4c1861de62e 
> 
> Diff: https://reviews.apache.org/r/47850/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 48076: GEODE-1463: Legacy OperationContexts do not set the appropriate Shiro permission tuple

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On June 1, 2016, 2:52 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48076/
> ---
> 
> (Updated June 1, 2016, 2:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Moved ResourceOperationContext into a 'public' package.
> - Converted OperationContext into an interface.
> - Cleaned up the hierarchy of everything that previously
>   extended OperationContext.
> - Marked GetOperationContext as abstract seeing that
>   GetOperationContextImpl extends it and there are no uses of
>   GetOperationContext anywhere. (So why does it still exist?).
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/CloseCQOperationContext.java
>  3a29981d0712bb9bb609731b818702a4d36f91cc 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/DestroyOperationContext.java
>  48ae9e519ecb10fa1209428b243e12d6f0cba0a1 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/ExecuteCQOperationContext.java
>  b4a07648726dc51ed4d9ec0ee68c2133af411c61 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/ExecuteFunctionOperationContext.java
>  e6bd455c0faa15e7ca63a6f96d8adb4f93043a8b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/GetDurableCQsOperationContext.java
>  a8de1a95e4aea8f077022fe0bb1d83bddf53c09b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/GetOperationContext.java
>  43b9e3aab0a20d2c149879bb04977631dd4e918a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/InterestOperationContext.java
>  79632551bd73e9d3806323fa29ca06704547c7f8 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/InvalidateOperationContext.java
>  75b0c3754e317a73b45cc5955edfbe3da0a162a6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/KeyOperationContext.java
>  71430afff5eeac8ed611461a7f2537bf25ffd9a1 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/KeySetOperationContext.java
>  5c0eeb91f0337e317a17c990eebc4331f90d3179 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/KeyValueOperationContext.java
>  7f7ab8c404ce7ac47643eaad9723f83780fcba55 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
>  317fee6b62d084716565f008d4d99ea6376b28dc 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/PutAllOperationContext.java
>  aff44962377f8862e40aa0ca029035780bc0c0c3 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/PutOperationContext.java
>  867c25617d96b9404875e0b738ea63295b7b4bf3 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/QueryOperationContext.java
>  f9711b7e64bfac5033805410dea7488439add9ec 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/RegionClearOperationContext.java
>  370ec6e87d67b03dd94f2eecd5f5777fedbe11e7 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/RegionCreateOperationContext.java
>  430ed084c4f564fddbf32f2358474b824951ab8a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/RegionDestroyOperationContext.java
>  d4693d04d88d8768ba0b73911716fcb701157b0b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/RegionOperationContext.java
>  ba199c6f84539cb474356c023cde251de67267ec 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/RegisterInterestOperationContext.java
>  4189c31c85b017d3a434fa6833301925bee5bd45 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/RemoveAllOperationContext.java
>  ebc3694d50abc219855ad7988f2a5f36bafb20b0 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/StopCQOperationContext.java
>  1c28f75aa4d12dc24daa30e784b87dbbce0b1ebd 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/UnregisterInterestOperationContext.java
>  078066e2575a812f66c2de42d4245ec6a35eb620 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/internal/GetOperationContextImpl.java
>  f664061cdb28b6fd0de0d2cede88d55062046b92 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/internal/ResourceOperationContext.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/execute/ServerToClientFunctionResultSender.java
>  14b81a19a618ad997d5fc389508c01f199d3c138 
>   
> 

Re: Review Request 48090: GEODE-1469: correctly handle the step arguements in http request

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On June 1, 2016, 6:38 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48090/
> ---
> 
> (Updated June 1, 2016, 6:38 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1469: correctly handle the step arguements in http request
> 
> rework. Turns out we need the expand operation of the UriComponents (some of 
> our uri do have variables in them). Rework by ending and decoding the stepArgs
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommands.java
>  5ddcc514e2a72a1ec584f2d8755b53df0e59f457 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/multistep/CLIMultiStepHelper.java
>  393f09bc7d92b61a24afdb8e3d4602488864f492 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/AbstractCommandsController.java
>  f78c6f924f27ce0ca2bae43c3663f97ee9cd4b98 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/ConfigCommandsController.java
>  ebacd3d6b9d5a49d5a5e20b7598674d1ba0ea146 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/support/LoginHandlerInterceptor.java
>  cefec91f74b499a60b21961dbbe997532a00da1d 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/http/ClientHttpRequest.java
>  447733d28dc7397ec0d968315152583194bb447f 
> 
> Diff: https://reviews.apache.org/r/48090/diff/
> 
> 
> Testing
> ---
> 
> prechecking running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 48150: GEODE-1185: typo in gfsh help on alter disk-store

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On June 1, 2016, 7:05 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48150/
> ---
> 
> (Updated June 1, 2016, 7:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1185: typo in gfsh help on alter disk-store
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java
>  241c9e217efb05ad1cb8bb5458cb86121e7848f9 
>   
> geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
>  74db3930d216fffa57342d215a520b935980d5e1 
> 
> Diff: https://reviews.apache.org/r/48150/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

[GitHub] incubator-geode issue #150: Feature/geode 308

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/incubator-geode/pull/150
  
+1


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

Build failed in Jenkins: Geode-spark-connector #23

[Apache Jenkins Server]

See 

Changes:

[jdeppe] GEODE-1455: Add SecurityTest JUnit category to outstanding gfsh / JMX

[jdeppe] GEODE-1454: Have "region" attribute, in JSONAuthorization json file be

[huynhja] GEODE-1316: Changing @since tags to @GemFire or @Geode

[eshu] GEODE-1400: An inflight transaction op could arrive later than a client

[upthewaterspout] GEODE-11: Adding a tool to dump the lucene index files

[upthewaterspout] GEODE-11 Adding stats for the lucene file system.

[upthewaterspout] GEODE-11 - Fixing failure in FileSystemJUnitTest

[huynhja] GEODE-11: Resolved compile warning for LuceneQueriesIntegrationTest

[upthewaterspout] GEODE-11: Adding a method to LuceneIndexImpl to dump indexes

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Initial move of system properties from private to 
public

[ukohlmeyer] GEODE-1377: Fixed Test

[ukohlmeyer] GEODE-1377: Renaming SystemConfigurationProperties to

[ukohlmeyer] GEODE-1377: Fixed missing import

--
[...truncated 1563 lines...]

M[info] Resolving net.sf.py4j#py4j;0.8.2.1 ...

M[info] Resolving 
org.apache.hadoop#hadoop-yarn-server-nodemanager;2.2.0 ...

M[info] Resolving 
org.apache.hadoop#hadoop-yarn-server-nodemanager;2.2.0 ...

M[info] Resolving 
org.apache.hadoop#hadoop-yarn-server;2.2.0 ...

M[info] Resolving org.apache.spark#spark-sql_2.10;1.3.0 
...

M[info] Resolving 
org.apache.spark#spark-catalyst_2.10;1.3.0 ...

M[info] Resolving org.scala-lang#scala-compiler;2.10.4 
...

M[info] Resolving org.scalamacros#quasiquotes_2.10;2.0.1 
...

M[info] Resolving com.twitter#parquet-column;1.6.0rc3 
...

M[info] Resolving com.twitter#parquet-common;1.6.0rc3 
...

M[info] Resolving com.twitter#parquet-encoding;1.6.0rc3 
...

M[info] Resolving com.twitter#parquet-generator;1.6.0rc3 
...

M[info] Resolving commons-codec#commons-codec;1.5 ...

M[info] Resolving com.twitter#parquet-hadoop;1.6.0rc3 
...

M[info] Resolving com.twitter#parquet-format;2.2.0-rc1 
...

M[info] Resolving com.twitter#parquet-jackson;1.6.0rc3 
...

M[info] Resolving 
org.codehaus.jackson#jackson-mapper-asl;1.9.11 ...

M[info] Resolving 
org.codehaus.jackson#jackson-core-asl;1.9.11 ...

M[info] Resolving org.jodd#jodd-core;3.6.3 ...

M[info] Resolving commons-net#commons-net;3.1 ...
[warn] there were 7 feature warning(s); re-run with -feature 
for details
[warn] one warning found
[info] Resolving 
org.scoverage#scalac-scoverage-runtime_2.10;1.0.4 ...

M[info] Resolving 
org.scoverage#scalac-scoverage-plugin_2.10;1.0.4 ...
[warn] Note: Some input files use unchecked or unsafe 
operations.
[warn] Note: Recompile with -Xlint:unchecked for details.
[info] Packaging 

 ...
[info] Done packaging.
[info] Resolving org.scala-lang#jline;2.10.4 ...

M[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Compiling 1 Scala source and 5 Java sources to 

[info] Packaging 

 ...
[info] Done packaging.
[success] Total time: 52 s, completed Jun 2, 2016 1:24:32 
PM
[info] 

Jenkins build is back to normal : Geode-nightly #487

[Apache Jenkins Server]

See 

RE: Async queue mechanism

[Gal Palmery]

Thanks Barry .

From: Barry Oglesby [mailto:bogle...@pivotal.io]
Sent: Wednesday, June 01, 2016 19:56
To: u...@geode.incubator.apache.org
Cc: geode (dev@geode.incubator.apache.org)
Subject: Re: Async queue mechanism

Sure. Its a pretty simple fix. When the xml is parsed, the AEQ's attributes are 
set into an intermediate object called an AsyncEventQueueCreation. The 
AsyncEventQueueImpl is instantiated based on this AsyncEventQueueCreation. 
During this processing, any configured GatewayEventFilters were left behind and 
not set on the AsyncEventQueueImpl. The fix was to not leave any configured 
GatewayEventFilters behind.

Thanks,
Barry Oglesby


On Tue, May 31, 2016 at 11:16 PM, Gal Palmery 
> wrote:
Thanks a lot Barry!
Can you pls share the quick explanation about the fix?

From: Barry Oglesby [mailto:bogle...@pivotal.io]
Sent: Wednesday, June 01, 2016 03:44
To: u...@geode.incubator.apache.org
Cc: geode 
(dev@geode.incubator.apache.org)
Subject: Re: Async queue mechanism

I see the issue. It looks like a merge issue. I have a fix that I'll check in 
in the next day or so.

Thanks,
Barry Oglesby


On Tue, May 31, 2016 at 12:52 PM, Barry Oglesby 
> wrote:
I see this same behavior. I'll look into it a bit more and let you know what I 
find.

Thanks,
Barry Oglesby


On Sun, May 29, 2016 at 5:38 AM, Gal Palmery 
> wrote:
+Adding the dev group

Thanks,
Gal

From: Gal Palmery
Sent: Sunday, May 29, 2016 15:30
To: u...@geode.incubator.apache.org
Subject: Async queue mechanism

Hi,

We are using the Async queue mechanism when inserting objects into the regions, 
which is defined as follows:


imdg.listeners.myClassFilter

< >

imdg.listeners.myClassSubstitutionFilter


imdg.listeners.myClassListener



In gemfire version 8.2,these were the steps for inserting the object to the 
queue :

· SubstitutionFilter : we are taking the required objects from the 
event object and return them as the result to the filter.

· Filter: beforeEnqueue method is invoked and it’s decided if the 
object will be passed to the listener. (In our filter classes - if the object 
is null we are not sending it to the listener)

· Listener: gets the de-serialized value, processes it puts it in the 
relevant regions.

Seems like in geode we are not passing through beforeEnqueue method in the 
Fillter step, and the null objects are not been filtered.
This means that when there is no object to pass through the queue, still null 
will be passed, and in the listener code, when asking for the de-serialized 
value,
we are getting also the null object, which results in a Null Pointer Exception.

Was anything changed recently in the Async queue mechanism?

Thanks,
Gal

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement, you may review at 
http://www.amdocs.com/email_disclaimer.asp