geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stolz <mst...@pivotal.io>
Subject Re: Orphaned Server processes
Date Wed, 05 Apr 2017 22:54:27 GMT
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 <mstolz@pivotal.io> 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 <ukohlmeyer@pivotal.io>
> wrote:
>
>> I disagree....
>>
>> +1 you can use stop/status by pointing at the directory where the server
>> is logging.
>>
>> -1 You cannot connect to the server and issue the command "create region"
>> or at the simplest "list members".
>>
>> The GFSH/management behavior should exactly the same as what one would
>> have when one is "connected" to the system via locator/jmx
>>
>> --Udo
>>
>>
>>
>> On 4/5/17 15:47, Kirk Lund wrote:
>>
>>> But you can interact with it...
>>>
>>> 1) You can issue "stop server --dir=server1" which will stop it
>>>
>>> 2) You can issue "status server --dir=server1" which will show the status
>>> for it
>>>
>>> 3) You can attach with JConsole and manipulate the MBeans. If the MBeans
>>> have operations to create something you can invoke those. You can even
>>> pass
>>> gfsh commands to the server via MemberMXBean#processCommand. Is this
>>> ideal?
>>> No, but it's still "interactive" and not "orphaned."
>>>
>>> 4) Geode has a search pattern to search for cache.xml and if it finds one
>>> it will use it. Perhaps the directly server1/ already exists and
>>> contains a
>>> cache.xml. Perhaps you have a cache.xml sitting in your user.home. So
>>> even
>>> if you specify the "start server --name=server1" as you state, it may
>>> still
>>> find a cache.xml to configure itself. I'm not saying this is better than
>>> using GFSH to configure the server, but it exists today and your proposal
>>> should explain how and why the search pattern for cache.xml is going away
>>> or something like that if you do in fact want this feature to go away.
>>>
>>> -Kirk
>>>
>>> On Wed, Apr 5, 2017 at 3:18 PM, Udo Kohlmeyer <ukohlmeyer@pivotal.io>
>>> wrote:
>>>
>>> Once again..
>>>>
>>>> you missing the point... starting a server with "start server
>>>> --name=server1".... without a locator or cache.xml or jmx-manager....
>>>> you
>>>> have created a useless server which you cannot interact with.... We
>>>> need to
>>>> avoid that...
>>>>
>>>> All the other discussions of how we can start an embedded locator or add
>>>> extra properties to the starting of the server... is just noise...
>>>>
>>>> The problem is... we allow for the creation of a server that cannot be
>>>> accessed other than through a client pool... Which as a matter of fact
>>>> cannot do anything with the server, OTHER than confirming it could
>>>> connect
>>>> to the server....
>>>>
>>>>
>>>>
>>>> On 4/5/17 13:10, Anilkumar Gingade wrote:
>>>>
>>>> One could create data model using cache.xml or embedded
>>>>> application/api...The server/node could be used as front-end cache for
>>>>> database to handle peek loads (or streamed data)....Client application
>>>>> can
>>>>> connect to the server and register interest, execute queries,
>>>>> function....
>>>>>
>>>>> -Anil.
>>>>>
>>>>>
>>>>> On Wed, Apr 5, 2017 at 11:03 AM, Udo Kohlmeyer <ukohlmeyer@pivotal.io>
>>>>> wrote:
>>>>>
>>>>> @Anil,
>>>>>
>>>>>> I agree... quick start to evaluate the product... "start server
>>>>>> --name=server1" is the simplest way to start a server... BUT there
>>>>>> are no
>>>>>> regions or anything ... So we really only have a GemFire process
that
>>>>>> does
>>>>>> not allow you to do anything with it... except connect to it from
a
>>>>>> client
>>>>>> and even the client cannot do anything with the server, because it
has
>>>>>> not
>>>>>> admin capability.
>>>>>>
>>>>>> --Udo
>>>>>>
>>>>>>
>>>>>> On 4/5/17 10:53, Anilkumar Gingade wrote:
>>>>>>
>>>>>> But does a use case for a server with no locator exist? What about
>>>>>> ease
>>>>>>
>>>>>>> of development?
>>>>>>>> I could see that it would be easier to start just a single
server
>>>>>>>> process instead of two (locator and server).
>>>>>>>>
>>>>>>>> Agree with Darrel, for someone who is evaluating the product,
it
>>>>>>> helps
>>>>>>> to
>>>>>>> build quick application and play around, without getting too
much
>>>>>>> into
>>>>>>> the
>>>>>>> cluster setup. Also, it is needed/helpful for use cases where
its
>>>>>>> used
>>>>>>> as
>>>>>>> embedded caching.
>>>>>>>
>>>>>>> -Anil.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 5, 2017 at 10:36 AM, Darrel Schneider <
>>>>>>> dschneider@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 <jiliao@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Without connecting to the server, I think you can still stop
it by
>>>>>>>>
>>>>>>>> specifying --pid or --dir in "stop server" command.
>>>>>>>>>
>>>>>>>>> On Wed, Apr 5, 2017 at 10:15 AM, Udo Kohlmeyer <
>>>>>>>>> ukohlmeyer@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message