geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <jb...@pivotal.io>
Subject Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members
Date Wed, 21 Feb 2018 18:12:56 GMT
Hi Jinmei-

Plain and simple, "development purposes".  I can easily debug such a server
when I can launch it from my IDE and I can still inspect the server using
*Gfsh*.  I may even launch and connect additional servers using Gfsh within
my IDE (or using *Gfsh*) that are connected to my *Boot* server,
particularly if that *Boot* server also embeds a *Locator*.

Primarily, I just want to be able to run commands that allow me to inspect
the server(s) (e.g. `list members`, `list regions`, `describe region`, etc).

Frequently, and more importantly, I run queries using the `query --query=...`
command to look at the data sent by clients.


3 questions...

1. What is the primary issue (limitations, etc) of supporting an embedded
*Manager* on a [cache] server?

I can understand in production, you don't want to have the additional
responsibility, load or security implications that comes with exposing the
Management service on a *CacheServer*.  However, I would argue the same
thing for a *Locator*.  If the *Locator(s)* go down because they were
overloaded by Management responsibilities, that has dire consequences for
the cluster.  E.g. I can no longer add members, clients may no longer be
able to connect (leveraging Single-Hop, Load-Balancing, and other
capabilities) and in a cloud environments (PCF using PCC) where
auto-scaling to the meet demand is critical, service reliability is at
risk.  After all, a *Manager* is "federating" are large amount of meta-data
from other members in the cluster, in memory.

Therefore, in my production cluster, I would prefer to have dedicated *Data
Nodes*, *CacheServers* (grouped), *Locators* and *Managers*, all separate.

2. What's the difference if the *CacheServer* also runs an embedded
*Locator* with Management services running vs a standalone *Locator/Manager*
?

3. Finally, how did we envision developers doing this during development
(I.e. launching servers, debugging, etc)?


Again, my desire to want a *CacheServer* with an embedded *Manager/Locator*
is also purely development-driven, for convenience and to iterate quickly,
easily.

Longer term, 1 of my visions is to improve on IDE support (e.g. with
plugins) that replace things like *Pulse's* *DataBrowser*, being able to do
most things inside the IDE instead, along with monitoring capabilities and
integration with *Spring Boot Actuator*, which is now based on *Micrometer*,
etc.

Thanks,
John



On Wed, Feb 21, 2018 at 8:35 AM, Jinmei Liao <jiliao@pivotal.io> wrote:

> Hi, John,  what's the intended usage of this jmx-manager on the
> cache-server when app developers started a cache-server that way in spring
> boot? Is that usually for pulse or other jmx client for monitoring purpose
> mostly? Or they would still want to connect using gfsh and execute bunch of
> commands to create regions/indexes etc? We are just wondering how much
> command support we should do for such jmx-managers.
>
> On Tue, Feb 20, 2018 at 3:05 PM, John Blum <jblum@pivotal.io> wrote:
>
> > So long as we **never** remove the ability to start an "embedded"
> > *Locator/Manager* in an [application] *CacheServer *process*, *which is
> > highly valuable during "*development*".
> >
> > For instance, I may want to spin up an application peer *CacheServer*
> > instance
> > with an embedded *Locator/Manager*, like this...
> >
> > https://github.com/jxblum/simplifying-apache-geode-with-
> > spring-data/blob/master/simplifying-apachegeode-
> > springdata-complete/src/main/java/example/app/server/
> > SpringBootApacheGeodeServerApplication.java
> >
> > Given this simple *Spring Boot *application class, it is real easy to
> form
> > a "*cluster of servers*" also just by changing the run profile
> > configuration in my IDE.
> >
> > Optionally, I should not have to start a *Manager* in my
> application-based
> > *CacheServer* even if I do start an embedded *Locator*.  Additionally,
> > while it might be less likely to occur, it is also nice to be able to
> start
> > an application-based *CacheServer* process with an embedded *Manager*
> > without having to start a *Locator* if I don't want to, since it is still
> > possible to connect to this node using *Gfsh*, like so...
> >
> > gfsh> connect --jmx-manager=localhost[1099]
> >
> > However, the real point is, as an application developer, I should not
> have
> > to go outside my IDE and use *Gfsh* to spin up separate
> > *Locator/Manager(s)*
> > and *CacheServer*(s), which is a non-starter for quick, iterative
> > development, particularly if I want to enable *debugging*, which is
> > significantly more difficult to do with *Gfsh* (not impossible, but
> > definitely more difficult).  *Gfsh* is not a "development" tool.
> >
> > -j
> >
>
>
>
> --
> Cheers
>
> Jinmei
>



-- 
-John
john.blum10101 (skype)

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