-1 for these reasons: 1) If an application needs Cache lifecycle notifications, we should expose that through an event mechanism (register a listener, invoke callbacks). 2) If there is an initialization bug where the CacheServer accepts connections and allows Cache operations prior to completing internal initialization, we should fix that bug.
Anthony > On Jan 5, 2017, at 12:55 PM, Kirk Lund <kl...@apache.org> wrote: > > So here's the what's going on: a User is starting Servers using "start > server" and apparently Clients are able to connect and perform operations > *before* the Cache has completed initialization. So now, I'm being asked to > change "start server" into a 2-command process (as an option): > > 1) gfsh> start server --name=Server1 --disable-default-server > 2) User waits until the Cache initialization is completed > 3) gfsh> start client-server-acceptor --name=Server1 > > I think this is crazy. If this is a problem then Geode Client/Server has a > bigger problem and this requires a fix in Cache initialization, NOT by > adding a new GFSH command. > > The launcher class used by GFSH is ServerLauncher, not the older deprecated > CacheServerLauncher. But what you're stating is still correct: > ServerLauncher starts the Client/Server acceptor AFTER the DS is connected > and Cache is created. > > So I'm trying to understand why we're trying to solve this in GFSH instead > of in the Server code. > > -Kirk > > > On Thu, Jan 5, 2017 at 12:43 PM, Dan Smith <dsm...@pivotal.io> wrote: > >> 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 >>>> >>> >>
