I'd like the server to refuse to start from gfsh if it can't reach a locator. That seems like exactly the correct behavior.
If you want to run a single node system for development, embedding a locator makes sense. Funny thing is, I don't know how to do that. Probably want an example for that somewhere. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Wed, Apr 5, 2017 at 1:36 PM, 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 > > >
