How are you starting up your system? If you initialize a system with a cache.xml or cluster configuration, the cache server and gateway acceptors are started last (see CacheCreation.create). If your cache server is started using gfsh start server, I believe the acceptor part is also started last (see CacheServerLauncher.createCache).
If you are using the API, it's up to you to start the cache server last. I don't think there is any latch we can add in that case unless we also added a method to indicate that you are done configuring the system. -Dan On Thu, Jan 5, 2017 at 11:20 AM, Michael Stolz <mst...@pivotal.io> wrote: > To be honest I always just thought it was there. I bet most users do. This > might explain some "unexplained" inconsistencies I have seen at a customer. > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: 631-835-4771 > > On Thu, Jan 5, 2017 at 2:09 PM, Kirk Lund <kl...@apache.org> wrote: > > > So, I'm looking into an issue in which the Geode Server starts up and > > accepts connections from Clients and starts handling their requests > before > > its Cache has completed initialization. > > > > Regions have a series of initialization latches that local puts and gets > > are forced to wait on. For example, initializationLatchAfterGetIni > > tialImage > > is released after GII completes for that Region. Local puts and gets are > > not allowed to be handled until after GII completes. > > > > I would expect the Cache to have an initialization latch as well that > > Client requests have to wait on before the Geode Server completes Cache > > initialization. > > > > Does anyone know why Cache or AcceptorImpl don't have an initialization > > latch like this? Does anyone have a good reason to not add such an > > initialization latch to protect incoming Client requests? > > > > Thanks, > > Kirk > > >
