Actually, the server KNOWS it is all by itself, and since that puts into an unusable state, why not just default to starting an embedded locator on the default port? Instant single-node GemFire.
-- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Wed, Apr 5, 2017 at 3:03 PM, Michael Stolz <mst...@pivotal.io> wrote: > We should add a "--start-locator=" option to the gfsh start server command > with the same semantics as the start-locator property > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: +1-631-835-4771 <(631)%20835-4771> > > On Wed, Apr 5, 2017 at 2:03 PM, William Markito Oliveira < > william.mark...@gmail.com> wrote: > >> Jianxia, you can set the property "start-locator" in gemfire.properties as >> below... So the server then will have an embedded locator. >> >> http://geode.apache.org/docs/guide/11/reference/topics/gemfi >> re_properties.html >> start-locator If set, automatically starts a locator in the current >> process >> when the member connects to the distributed system and stops the locator >> when the member disconnects. >> >> To use, specify the locator with an optional address or host specification >> and a required port number, in one of these formats: >> >> start-locator=address[port1] >> >> start-locator=port1 >> >> If you only specify the port, the address assigned to the member is used >> for the locator. >> >> If not already there, this locator is automatically added to the list of >> locators in this set of gemfire properties. >> *not set* >> >> On Wed, Apr 5, 2017 at 12:50 PM, Jianxia Chen <jc...@pivotal.io> wrote: >> >> > Hi Darrel, >> > >> > How to configure a colocated locator in the same server process? Just >> > curious. What I understand is that the locator is in its own process. >> > >> > Thanks, >> > Jianxia >> > >> > 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 >> > > > >> > > >> > >> >> >> >> -- >> ~/William >> > >
