Re: New APIs, read-serialized and CacheListeners, PostProcessor etc

in addition to not breaking existing callbacks, new getvalue mechanisms should be created that support either getting the serialized or deserialized value on the call itself rather than at the thread level or the entire cache level. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1

Build failed in Jenkins: Geode-nightly #1145

See Changes: [github] GEODE-4827: null check for the cache. (#1646) [bschuchardt] Revert "GEODE-4928 DistributedLockService doesn't work as expected while [klund] GEODE-1279: Rename Bug51616JUnitTest as [klund]

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

--- Spring Data GemFire > Nightly-ApacheGeode > #868 was successful (rerun once). --- This build was rerun by John Blum. 2383 tests in total. https://build.sprin

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #868 has FAILED (2 tests failed)

--- Spring Data GemFire > Nightly-ApacheGeode > #868 failed. --- Scheduled 2/2383 tests failed. https://build.spring.io/browse/SGF-NAG-868/

New APIs, read-serialized and CacheListeners, PostProcessor etc

Hi all, We're working on a new protocol for Geode, which means wrapping Geode APIs and exposing them via the new protocol. For performance and to avoid class/serialization logic, we want to get these objects in serialized form. This means calling cache.setReadSerializedForCurrentThread(true) while

Re: Geode unit tests 'develop/DistributedTest' took too long to execute

It looks like the CI run hung in a test that I introduced on Friday.  I'm looking into it. "RMI TCP Connection(2)-172.17.0.7" #112 daemon prio=5 os_prio=0 tid=0x7f63b0003000 nid=0x333 waiting on condition [0x7f64411cc000]    java.lang.Thread.State: TIMED_WAITING (parking)     at sun.mi

Re: Membership log message questions

Thanks Bruce! I'll change the test to use crashDistributedSystem. On Mon, Mar 26, 2018 at 8:49 AM, Bruce Schuchardt wrote: > The problem is that the test is shutting down the cache in a high-priority > thread pool. When the ClusterDistributionManager tries to close its thread > pools it waits a

Re: Membership log message questions

The problem is that the test is shutting down the cache in a high-priority thread pool.  When the ClusterDistributionManager tries to close its thread pools it waits a while for their threads to exit, so the thread ends up waiting for itself to exit & that's not going to happen.  During that ti

Re: Membership log message questions

This is weird behavior Kirk.  It looks like vm0 was behaving very badly - I'll check into it. On 3/22/18 7:58 PM, Kirk Lund wrote: If anyone really wants to look at and run the test directly, it's *Bug41733DUnitTest* on develop. Alternatively, you could pull the branch GEODE-1279-rename-regre