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