[VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

Hello Geode Dev Community, This is a release candidate for Apache Geode version 1.11.0.RC3. Thanks to all the community members for their contributions to this release! Please do a review and give your feedback, including the checks you performed. Voting deadline: 11AM PST Monday December 2

Passed: apache/geode-native#2233 (rel/v1.11.0.RC3 - 5d01219)

Build Update for apache/geode-native - Build: #2233 Status: Passed Duration: 1 hr, 38 mins, and 58 secs Commit: 5d01219 (rel/v1.11.0.RC3) Author: Jacob Barrett Message: GEODE-7418: Fixes issue deserializing unregistered PDX types. (#546) * GEODE-7418: Fixes

Errored: apache/geode-examples#393 (rel/v1.11.0.RC3 - 8bb28ea)

Build Update for apache/geode-examples - Build: #393 Status: Errored Duration: 1 min and 39 secs Commit: 8bb28ea (rel/v1.11.0.RC3) Author: Mark Hanson Message: temporarily point to staging repo for CI purposes View the changeset:

Re: Cache.close is not synchronous?

Looking at the code, the cache.close() and InternalCacheBuilder.create() are synchronized on "GemFireCacheImpl.class"'; it's the internalCachebuilder create that seems to be using reference to the old distributed-system. The GemFireCacheImpl.getInstance() and getExisting() both perform "isClosing"

Re: Cache.close is not synchronous?

+1 to fix. > On Nov 25, 2019, at 2:02 PM, John Blum wrote: > > +1 ^ 64! > > I found this out the hard way some time ago and is why STDG exists in the > first place (i.e. usability issues, particularly with testing). > > On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund wrote: > >> I found a test

Re: Cache.close is not synchronous?

+1 ^ 64! I found this out the hard way some time ago and is why STDG exists in the first place (i.e. usability issues, particularly with testing). On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund wrote: > I found a test that closes the cache and then recreates the cache multiple > times with 2 second

Cache.close is not synchronous?

I found a test that closes the cache and then recreates the cache multiple times with 2 second sleep between each. I tried to remove the Thread.sleep and found that recreating the cache throws DistributedSystemDisconnectedException (see below). This seems like a usability nightmare. Anyone have

Re: Async queue mechanism

Can you check your locator log file? You should see a message like this: [info 2019/11/25 09:39:35.432 PST tid=0x55] Executing command: create async-event-queue --id=sampleq7 --listener=test.gemfire.GemFireListener And then the exception with stack like: [error 2019/11/25 09:56:19.507 PST

Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

Thanks for the feedback. We have rough consensus for the new module so we will make it so. On Mon, Nov 18, 2019 at 5:34 PM Joris Melchior wrote: > +1 > > On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols wrote: > > > +1 > > > > > On Nov 18, 2019, at 3:00 PM, Nabarun Nag wrote: > > > > > > +1 > > >

Re: WAN Get-Initial-Image

DId you run "create async-event-queue"? On Mon, Nov 25, 2019 at 9:23 AM anjana_nair wrote: > Hi, > > We are trying to solve cloud replication using > asyncEventListeners.However > the sample AsyncEventListener is not getting fired when I try a put. Could > you please look into this. Commands

Re: [DISCUSS] - Move gfsh into its own submodule

+ힹ — Dale Emery dem...@pivotal.io > On Nov 22, 2019, at 8:39 AM, Jens Deppe wrote: > > Hello All, > > We'd like to propose moving gfsh and all associated commands into its own > gradle submodule (implicitly thus also producing a separate maven > artifact). The underlying intent is to

Re: WAN Get-Initial-Image

Hi, We are trying to solve cloud replication using asyncEventListeners.However the sample AsyncEventListener is not getting fired when I try a put. Could you please look into this. Commands tried out are below. I am starting to write an AsyncEventListener to store messages to

RE: Async queue mechanism

Hi, I am trying to create a an asyncEventqueue thru gfsh and it gives me the error below : gfsh>create async-event-queue --id=sampleq7 --listener=test.gemfire.GemFireListener Could not process command due to error. Error while processing command Reason : No results received. Sever throws no

RE: Help to reproduce GEODE-7060

Ok, then Im going to close the ticket. Thanks for the info Blake! De: Blake Bender Enviado: lunes, 25 de noviembre de 2019 15:11 Para: dev@geode.apache.org Asunto: Re: Help to reproduce GEODE-7060 Hi Alberto, I apologize for the mention of gemfire-node-client

Re: Help to reproduce GEODE-7060

Hi Alberto, I apologize for the mention of gemfire-node-client in OSS Geode JIRA, this is a proprietary product that you don't have access to. For the time being, I believe, we have fixed all of the ACE leaks we've found, so GEODE-7060 can be safely closed. Just for context, we found that, on

Help to reproduce GEODE-7060

Hi, I need some info to reproduce the issue described in GEODE-7060, about an ACE resource leak. The ticket says the problem was seen using a test called "gemfire-node-client putall.js", but I suppose that test is not part of Geode. Could someone with access to that test describe what it is