In general, I think it would be useful to have a `start/stop/status *service*` where services could be any one of [CacheServer, GatewayReceiver, RedisService, MemcachedService, HttpService, etc]. As user/developer, it would be useful to be able to control the embedded services in one or more GemFire/Geode nodes in the cluster.
On Thu, Jan 5, 2017 at 1:57 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > +2 > > > > On 1/5/17 13:53, Kirk Lund wrote: > >> 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 >>>>>>> >>>>>>> >>>>>>> > -- -John john.blum10101 (skype)
