I think the current behavior is probably left over from the multicast member discovery days, which are...thankfully...behind us.
-- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Wed, Apr 5, 2017 at 6:53 PM, Michael Stolz <mst...@pivotal.io> wrote: > Anyway, at the very least it's an unusual configuration, so it would be > best if it required some explicit option to start server to say "Yes I know > what I'm doing...I really want a server that has no peers and no locator." > > Without that explicit acknowledgement it should just fail and report the > reason why. > > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 <(631)%20835-4771> > > On Wed, Apr 5, 2017 at 6:50 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > >> I disagree.... >> >> +1 you can use stop/status by pointing at the directory where the server >> is logging. >> >> -1 You cannot connect to the server and issue the command "create region" >> or at the simplest "list members". >> >> The GFSH/management behavior should exactly the same as what one would >> have when one is "connected" to the system via locator/jmx >> >> --Udo >> >> >> >> On 4/5/17 15:47, Kirk Lund wrote: >> >>> But you can interact with it... >>> >>> 1) You can issue "stop server --dir=server1" which will stop it >>> >>> 2) You can issue "status server --dir=server1" which will show the status >>> for it >>> >>> 3) You can attach with JConsole and manipulate the MBeans. If the MBeans >>> have operations to create something you can invoke those. You can even >>> pass >>> gfsh commands to the server via MemberMXBean#processCommand. Is this >>> ideal? >>> No, but it's still "interactive" and not "orphaned." >>> >>> 4) Geode has a search pattern to search for cache.xml and if it finds one >>> it will use it. Perhaps the directly server1/ already exists and >>> contains a >>> cache.xml. Perhaps you have a cache.xml sitting in your user.home. So >>> even >>> if you specify the "start server --name=server1" as you state, it may >>> still >>> find a cache.xml to configure itself. I'm not saying this is better than >>> using GFSH to configure the server, but it exists today and your proposal >>> should explain how and why the search pattern for cache.xml is going away >>> or something like that if you do in fact want this feature to go away. >>> >>> -Kirk >>> >>> On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> >>> wrote: >>> >>> Once again.. >>>> >>>> you missing the point... starting a server with "start server >>>> --name=server1".... without a locator or cache.xml or jmx-manager.... >>>> you >>>> have created a useless server which you cannot interact with.... We >>>> need to >>>> avoid that... >>>> >>>> All the other discussions of how we can start an embedded locator or add >>>> extra properties to the starting of the server... is just noise... >>>> >>>> The problem is... we allow for the creation of a server that cannot be >>>> accessed other than through a client pool... Which as a matter of fact >>>> cannot do anything with the server, OTHER than confirming it could >>>> connect >>>> to the server.... >>>> >>>> >>>> >>>> On 4/5/17 13:10, Anilkumar Gingade wrote: >>>> >>>> One could create data model using cache.xml or embedded >>>>> application/api...The server/node could be used as front-end cache for >>>>> database to handle peek loads (or streamed data)....Client application >>>>> can >>>>> connect to the server and register interest, execute queries, >>>>> function.... >>>>> >>>>> -Anil. >>>>> >>>>> >>>>> On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> >>>>> wrote: >>>>> >>>>> @Anil, >>>>> >>>>>> I agree... quick start to evaluate the product... "start server >>>>>> --name=server1" is the simplest way to start a server... BUT there >>>>>> are no >>>>>> regions or anything ... So we really only have a GemFire process that >>>>>> does >>>>>> not allow you to do anything with it... except connect to it from a >>>>>> client >>>>>> and even the client cannot do anything with the server, because it has >>>>>> not >>>>>> admin capability. >>>>>> >>>>>> --Udo >>>>>> >>>>>> >>>>>> On 4/5/17 10:53, Anilkumar Gingade wrote: >>>>>> >>>>>> But does a use case for a server with no locator exist? What about >>>>>> ease >>>>>> >>>>>>> of development? >>>>>>>> I could see that it would be easier to start just a single server >>>>>>>> process instead of two (locator and server). >>>>>>>> >>>>>>>> Agree with Darrel, for someone who is evaluating the product, it >>>>>>> helps >>>>>>> to >>>>>>> build quick application and play around, without getting too much >>>>>>> into >>>>>>> the >>>>>>> cluster setup. Also, it is needed/helpful for use cases where its >>>>>>> used >>>>>>> as >>>>>>> embedded caching. >>>>>>> >>>>>>> -Anil. >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider < >>>>>>> dschnei...@pivotal.io> >>>>>>> wrote: >>>>>>> >>>>>>> I like the idea of servers failing to start if no locator exists. >>>>>>> >>>>>>> But does a use case for a server with no locator exist? What about >>>>>>>> ease >>>>>>>> of >>>>>>>> development? >>>>>>>> >>>>>>>> I could see that it would be easier to start just a single server >>>>>>>> process >>>>>>>> instead of two (locator and server). But for this use case couldn't >>>>>>>> the >>>>>>>> developer just configure a colocated locator in the same server >>>>>>>> process? >>>>>>>> This would have the benefit of the clients during development and >>>>>>>> production using a locator consistently. >>>>>>>> >>>>>>>> Is it true that the server with no locator will never have any peer >>>>>>>> members >>>>>>>> in its cluster? >>>>>>>> Clients can still connect to this singleton server by being >>>>>>>> configured >>>>>>>> with >>>>>>>> the server host and port instead of the locator. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 5, 2017 at 10:24 AM, Jinmei Liao <jil...@pivotal.io> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Without connecting to the server, I think you can still stop it by >>>>>>>> >>>>>>>> specifying --pid or --dir in "stop server" command. >>>>>>>>> >>>>>>>>> On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer < >>>>>>>>> ukohlme...@pivotal.io >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hey there, >>>>>>>>> >>>>>>>>> Current Geode allows a user to start a server without being linked >>>>>>>>>> to a >>>>>>>>>> Locator. Which in itself is not incorrect, but once started there >>>>>>>>>> is >>>>>>>>>> no >>>>>>>>>> >>>>>>>>>> way >>>>>>>>>> >>>>>>>>> to connect to that server to manage it. >>>>>>>>> >>>>>>>>>> I know that we have taken an opinionated view that member >>>>>>>>>> discovery >>>>>>>>>> can >>>>>>>>>> only now happen through a locator and that multicast is an option >>>>>>>>>> >>>>>>>>>> anymore. >>>>>>>>>> >>>>>>>>> Can we take the same opinionated view where we either state that >>>>>>>>> >>>>>>>>>> unless >>>>>>>>>> your server is connecting to a locator, it cannot be started OR we >>>>>>>>>> fix >>>>>>>>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>> default behavior where we can start a server but cannot connect to >>>>>>>>> it, >>>>>>>>> >>>>>>>>>> and >>>>>>>>>> >>>>>>>>> have to resort to "kill -9" commands to kill the server. >>>>>>>>> >>>>>>>>>> --Udo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> >>>>>>>>> Jinmei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >
