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 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >
