Udo - could your use case be satisfied just by doing somthing like this? 1) gfsh start server --disable-default-server 2) Run your custom code 3) As the last part of your custom code, call Cache.addCacheServer
-Dan 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 >>>>> >>>>> >
