Re: Orphaned Server processes

[Jens Deppe]

Also, don't forget that you can start a server in a 'wait for locator' mode
(I forget the actual option) which should be distinguished from an actual
'orphaned' instance.

--Jens

On Wed, Apr 5, 2017 at 3:54 PM, Michael Stolz  wrote:

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

Re: Orphaned Server processes

[Michael Stolz]

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

Re: Orphaned Server processes

[Michael Stolz]

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

Re: Orphaned Server processes

[Udo Kohlmeyer]

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

Re: Orphaned Server processes

[Kirk Lund]

"--start-locator=" was originally present on "start server" but was
commented out for some reason. You can find the lines in CliStrings.java:

// public static final String START_SERVER__START_LOCATOR = "start-locator";
// public static final String START_SERVER__START_LOCATOR__HELP =
// "To start embedded Locator with given endpoints in the format:
host[port]. If no endpoints are
// given defaults (localhost[10334]) are assumed.";

I don't know why it was removed or why it was dead-coded instead of
deleting it.

-Kirk

On Wed, Apr 5, 2017 at 3:18 PM, Swapnil Bawaskar 
wrote:

> +1 to add a "--start-locator=" option for starting an embedded locator.
> However, I can easily see a user starting two servers and expecting to form
> a distributed system, but if we start the embedded locator by default, they
> won't.
> So, I think we should prevent the server from starting up, but give an
> error message to either start a locator or use the --start-locator option.
>
> On Wed, Apr 5, 2017 at 2:50 PM Kirk Lund  wrote:
>
> > You can still control a lone server with GFSH. And if you configure it up
> > front, then you can still have Regions for a Client to use.
> >
> > $ start server --name=server1 --cache-xml-file=mycachefile.xml
> >
> > 
> >
> > $ stop server --dir=server1
> >
> > You could also start a JMX Manager in the server or an embedded Locator
> as
> > others have mentioned. I'm not sure if it's possible to startup cluster
> > config service in a server or if that comes for free when you start an
> > embedded Locator.
> >
> > -Kirk
> >
> > On Wed, Apr 5, 2017 at 12:26 PM, Jianxia Chen  wrote:
> >
> > > Thanks Jinmei! You are right. I missed that.
> > >
> > > Thanks,
> > > Jianxia
> > >
> > > On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao 
> wrote:
> > >
> > > > for your #1, there is a --properties-file option when you do "start
> > > > server".
> > > >
> > > > On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen 
> > wrote:
> > > >
> > > > > Thank you William!
> > > > >
> > > > > I tried with it. It works. But there is something tricky in order
> to
> > > > start
> > > > > the embedded locator.
> > > > >
> > > > > 1) the gemfire.properties file has to be in the right place, either
> > in
> > > > the
> > > > > server directory or home directory. Looks like this is not
> > documented.
> > > > > I was trying to specify the properties file in gfsh when starting
> > > server.
> > > > > However, there is no such option for `start server` command. There
> is
> > > an
> > > > > `--security-properties-file` option though, for
> > gfsecurity.properties.
> > > > >
> > > > > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> > > > start.
> > > > > The server can be started successfully though.
> > > > >
> > > > > Thanks,
> > > > > Jianxia
> > > > >
> > > > > On Wed, Apr 5, 2017 at 11:03 AM, 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/
> > > > > > gemfire_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 
> > > > 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 

Re: Orphaned Server processes

[Kirk Lund]

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

Re: Orphaned Server processes

[Udo Kohlmeyer]

My apologies,

"you" should not be interpreted as personal.

I'm highlighting that a server can be created without any configuration, 
which allows for an orphan server. A solution should be found for 
that either through failing or starting a means that can correctly 
administer the server.


--Udo


On 4/5/17 15:25, Anilkumar Gingade wrote:

Udo,

I was commenting on the statement:

Current Geode allows a user to start a server without being linked to a

Locator.
Not specifically starting server with gfsh...

-Anil.









On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer  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 
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 
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 

Re: Orphaned Server processes

[Anilkumar Gingade]

Udo,

I was commenting on the statement:
>> Current Geode allows a user to start a server without being linked to a
Locator.
Not specifically starting server with gfsh...

-Anil.









On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer  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 
>> 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 
> 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 > >
>> 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
>>
>>
>>
>

Re: Orphaned Server processes

[Swapnil Bawaskar]

+1 to add a "--start-locator=" option for starting an embedded locator.
However, I can easily see a user starting two servers and expecting to form
a distributed system, but if we start the embedded locator by default, they
won't.
So, I think we should prevent the server from starting up, but give an
error message to either start a locator or use the --start-locator option.

On Wed, Apr 5, 2017 at 2:50 PM Kirk Lund  wrote:

> You can still control a lone server with GFSH. And if you configure it up
> front, then you can still have Regions for a Client to use.
>
> $ start server --name=server1 --cache-xml-file=mycachefile.xml
>
> 
>
> $ stop server --dir=server1
>
> You could also start a JMX Manager in the server or an embedded Locator as
> others have mentioned. I'm not sure if it's possible to startup cluster
> config service in a server or if that comes for free when you start an
> embedded Locator.
>
> -Kirk
>
> On Wed, Apr 5, 2017 at 12:26 PM, Jianxia Chen  wrote:
>
> > Thanks Jinmei! You are right. I missed that.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao  wrote:
> >
> > > for your #1, there is a --properties-file option when you do "start
> > > server".
> > >
> > > On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen 
> wrote:
> > >
> > > > Thank you William!
> > > >
> > > > I tried with it. It works. But there is something tricky in order to
> > > start
> > > > the embedded locator.
> > > >
> > > > 1) the gemfire.properties file has to be in the right place, either
> in
> > > the
> > > > server directory or home directory. Looks like this is not
> documented.
> > > > I was trying to specify the properties file in gfsh when starting
> > server.
> > > > However, there is no such option for `start server` command. There is
> > an
> > > > `--security-properties-file` option though, for
> gfsecurity.properties.
> > > >
> > > > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> > > start.
> > > > The server can be started successfully though.
> > > >
> > > > Thanks,
> > > > Jianxia
> > > >
> > > > On Wed, Apr 5, 2017 at 11:03 AM, 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/
> > > > > gemfire_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 
> > > 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 

Re: Orphaned Server processes

[Udo Kohlmeyer]

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

Re: Orphaned Server processes

[Kirk Lund]

You can still control a lone server with GFSH. And if you configure it up
front, then you can still have Regions for a Client to use.

$ start server --name=server1 --cache-xml-file=mycachefile.xml



$ stop server --dir=server1

You could also start a JMX Manager in the server or an embedded Locator as
others have mentioned. I'm not sure if it's possible to startup cluster
config service in a server or if that comes for free when you start an
embedded Locator.

-Kirk

On Wed, Apr 5, 2017 at 12:26 PM, Jianxia Chen  wrote:

> Thanks Jinmei! You are right. I missed that.
>
> Thanks,
> Jianxia
>
> On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao  wrote:
>
> > for your #1, there is a --properties-file option when you do "start
> > server".
> >
> > On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen  wrote:
> >
> > > Thank you William!
> > >
> > > I tried with it. It works. But there is something tricky in order to
> > start
> > > the embedded locator.
> > >
> > > 1) the gemfire.properties file has to be in the right place, either in
> > the
> > > server directory or home directory. Looks like this is not documented.
> > > I was trying to specify the properties file in gfsh when starting
> server.
> > > However, there is no such option for `start server` command. There is
> an
> > > `--security-properties-file` option though, for gfsecurity.properties.
> > >
> > > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> > start.
> > > The server can be started successfully though.
> > >
> > > Thanks,
> > > Jianxia
> > >
> > > On Wed, Apr 5, 2017 at 11:03 AM, 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/
> > > > gemfire_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 
> > 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 
> > > > 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
> > > 

Re: Orphaned Server processes

[Anilkumar Gingade]

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


>

Re: Orphaned Server processes

[Jianxia Chen]

Thanks Jinmei! You are right. I missed that.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 12:24 PM, Jinmei Liao  wrote:

> for your #1, there is a --properties-file option when you do "start
> server".
>
> On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen  wrote:
>
> > Thank you William!
> >
> > I tried with it. It works. But there is something tricky in order to
> start
> > the embedded locator.
> >
> > 1) the gemfire.properties file has to be in the right place, either in
> the
> > server directory or home directory. Looks like this is not documented.
> > I was trying to specify the properties file in gfsh when starting server.
> > However, there is no such option for `start server` command. There is an
> > `--security-properties-file` option though, for gfsecurity.properties.
> >
> > 2) jmx-manager has to be true. Otherwise the embedded locator won't
> start.
> > The server can be started successfully though.
> >
> > Thanks,
> > Jianxia
> >
> > On Wed, Apr 5, 2017 at 11:03 AM, 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/
> > > gemfire_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 
> 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 
> > > 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
> > >
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Re: Orphaned Server processes

[Jinmei Liao]

for your #1, there is a --properties-file option when you do "start server".

On Wed, Apr 5, 2017 at 12:20 PM, Jianxia Chen  wrote:

> Thank you William!
>
> I tried with it. It works. But there is something tricky in order to start
> the embedded locator.
>
> 1) the gemfire.properties file has to be in the right place, either in the
> server directory or home directory. Looks like this is not documented.
> I was trying to specify the properties file in gfsh when starting server.
> However, there is no such option for `start server` command. There is an
> `--security-properties-file` option though, for gfsecurity.properties.
>
> 2) jmx-manager has to be true. Otherwise the embedded locator won't start.
> The server can be started successfully though.
>
> Thanks,
> Jianxia
>
> On Wed, Apr 5, 2017 at 11:03 AM, 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/
> > gemfire_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  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 
> > 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
> >
>



-- 
Cheers

Jinmei

Re: Orphaned Server processes

[Jianxia Chen]

Thank you William!

I tried with it. It works. But there is something tricky in order to start
the embedded locator.

1) the gemfire.properties file has to be in the right place, either in the
server directory or home directory. Looks like this is not documented.
I was trying to specify the properties file in gfsh when starting server.
However, there is no such option for `start server` command. There is an
`--security-properties-file` option though, for gfsecurity.properties.

2) jmx-manager has to be true. Otherwise the embedded locator won't start.
The server can be started successfully though.

Thanks,
Jianxia

On Wed, Apr 5, 2017 at 11:03 AM, 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/
> gemfire_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  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  >
> > 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 
> 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
>

Re: Orphaned Server processes

[Udo Kohlmeyer]

That could be another option that could be pursued...


On 4/5/17 12:05, Michael Stolz wrote:

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

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

Re: Orphaned Server processes

[Michael Stolz]

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

Re: Orphaned Server processes

[Michael Stolz]

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

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

Re: Orphaned Server processes

[Udo Kohlmeyer]

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

Re: Orphaned Server processes

[William Markito Oliveira]

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

Re: Orphaned Server processes

[Udo Kohlmeyer]

I think an embedded server makes sense. No locator required, UNLESS you 
want to form a cluster and then I think you need a locator. (haven't 
tried this without multicast)


Shutting down a server with --pid or --dir works. BUT... One cannot 
connect to a default server "start server --name=server1". This is a 
server that can only be connected to directly from a client, BUT the 
client cannot do any admin (create region, etc)... So in essence when 
starting a server without locator or management interfaces (REST,JMX) 
enabled, just wastes space and cannot be managed...


I'd like to suggest that if we start an "orphan" server, it either does 
not allow it to be started, because it is really just sitting there 
without any management capability OR we detect that no management 
interfaces have been configured and start the JMX manager to allow for 
management.


--Udo
On 4/5/17 10:36, Darrel Schneider 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  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 
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

Re: Orphaned Server processes

[Anilkumar Gingade]

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

Re: Orphaned Server processes

[Jianxia Chen]

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

Re: Orphaned Server processes

[Michael Stolz]

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

Re: Orphaned Server processes

[Darrel Schneider]

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

Re: Orphaned Server processes

[Jinmei Liao]

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