Ok #3 makes sense then. It's not that the Cache initialization is broken, it's that some people want to hook in some custom initialization at the end of cache creation but before starting the ClientServer component.
I think it would make the most sense to have Cache initialization callbacks (this has been commonly requested by users for as long as I can remember). It would also make sense to add lifecycle control commands for starting and stopping the ClientServer component (since this isn't a workaround for some sinister bug). If we design the start clientserver command correctly then it's one more step towards completing cluster config in such a way that no one needs cache.xml anymore. Right now if a user wants to create multiple ClientServer endpoints then they have to use cache.xml in addition to starting the default-server with the start server command. On Thu, Jan 5, 2017 at 1:17 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > Take this scenario as an example. > > 1) start server > 2) Cache initializes and starts cacheserver > 3) run custom code to build up meta structures for custom implementation > > In this scenario, the cache has initialized and the cacheserver has been > started. So clients can start interacting with the server whilst it is > trying to build up custom add meta structures. Which may mean that the > client could receive incorrect results for queries or incorrect behavior > due to the data structures being "not ready" > > If the capability is introduced to manually start the cacheserver then > this could go away. > > 1) start server > 2) Cache initializes > 3) run custom code to build up meta structures for custom implementation > 4) start cacheserver > > I agree, adding this flag because it did not correctly initialize the > cache/region/data structures that is crazy. If there is an issue where a > server has started up and is still waiting to GII messages, that should be > addressed as a bug. > > --Udo > > > On 1/5/17 12:55, Kirk Lund 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 >>>>> >>>>> >
