[PROPOSAL] Deprecate running JMX Manager on non-locator members

[Jens Deppe <je...@apache.org>]

TL;DR I'd like to propose that we deprecate and ultimately remove the
ability to run a JMX manager on a non-locator member.

I'm not sure about the history for this capability and the original use
cases but I imagine it would have been driven, to a large part, by the
ability for member discovery without locators. Since we have removed that
(and always require locators) it seems that at least one requirement is no
longer valid.

Does anyone have any other use cases where having a JMX manager on a
non-locator would be a requirement?

Thanks
--Jens

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[Kirk Lund <kl...@apache.org>]

If you're talking about GFSH commands only... removing JMX manager options
from "start server" then that's probably reasonable.

But as John described better than me, I wouldn't make
non-dedicated-locators unable to host certain services such as JMX manager
or locator.

For example, it wasn't easy to remove the restriction that locators
couldn't have a cache. Following in that direction again is the wrong way
for Geode.

On Wed, Feb 21, 2018 at 4:47 PM, John Blum <jb...@pivotal.io> wrote:

> What you described is a consequence of its current design/implementation, a
> tightly coupled one at that.
>
> * Why does the "Configuration Service" have to be limited to *Locators*?
>
> * Likewise, why would a "Management Service" be limited to *Managers*?
>
> I think of the later (*Locators/Managers*) as "dedicated processes"
> assigned with certain "responsibilities" (or functions), primarily
> "Location-based/aware services" and "Management services", respectively.
>
> While processes (in the distributed system) may serve in particular roles
> and have certain responsibilities, by no means should "Services" be tied to
> only to dedicated processes; it's a "Service" after all, with its own API
> and set of provider implementations, etc.  Process is context and Service
> is function, which is also an important distinction with consideration to
> Security.
>
> Expanding on this concept, the Configuration Service could also be charged
> with providing/serving the current configuration (not just recording it),
> and both the Configuration Service and Management Service could be grouped
> together as part of a larger, composite service, like an Administrative
> Service, since both are indeed related functions to a certain degree.
>
> Food for thought,
>
> -j
>
>
>
> On Wed, Feb 21, 2018 at 2:57 PM, Jens Deppe <jd...@pivotal.io> wrote:
>
> > One thing that prompted this initial proposal is that our (management and
> > monitoring) service boundaries, (or one could say APIs), are not well
> > defined.
> >
> > Case in point; we currently have a 'configuration service' which is used
> to
> > persist configuration. This service is only available on locators. The
> > 'management service' (as defined/used by gfsh to manipulate
> configuration)
> > can exist on both locators and servers. If it runs on servers then it
> > suddenly does not have access to the configuration service.
> >
> > It almost feels like we need more capabilities around
> > distributed/discoverable micro-services inside Geode.
> >
> > --Jens
> >
> > On Wed, Feb 21, 2018 at 10:44 AM, John Blum <jb...@pivotal.io> wrote:
> >
> > > Typo; Sorry!
> > >
> > > This..
> > >
> > > > 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*.
> > >
> > > should have read...
> > >
> > > > I may even launch and connect additional servers *within my IDE* (or
> > > using
> > >  *Gfsh*) that are connected to my *Boot* server, particularly if that
> > > *Boot*
> > >  server also embeds a *Locator*.
> > >
> > >
> > > On Wed, Feb 21, 2018 at 10:25 AM, Kirk Lund <kl...@apache.org> wrote:
> > >
> > > > Most of the geode developers are working to get rid of singleton
> calls
> > > (and
> > > > next up static code) with the goal of being able to have multiple
> Cache
> > > > instances in one JVM. This is to facilitate writing geode and geode
> > > > application tests in one JVM. This fits in with what John is saying
> as
> > > > well.
> > > >
> > > > Basically, don't make any changes that are going to make testing more
> > > > difficult or prevent running everything in geode within one JVM.
> > > >
> > > > On Wed, Feb 21, 2018 at 10:12 AM, John Blum <jb...@pivotal.io>
> wrote:
> > > >
> > > > > 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 <ji...@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 <jb...@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)
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -John
> > > john.blum10101 (skype)
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[John Blum <jb...@pivotal.io>]

What you described is a consequence of its current design/implementation, a
tightly coupled one at that.

* Why does the "Configuration Service" have to be limited to *Locators*?

* Likewise, why would a "Management Service" be limited to *Managers*?

I think of the later (*Locators/Managers*) as "dedicated processes"
assigned with certain "responsibilities" (or functions), primarily
"Location-based/aware services" and "Management services", respectively.

While processes (in the distributed system) may serve in particular roles
and have certain responsibilities, by no means should "Services" be tied to
only to dedicated processes; it's a "Service" after all, with its own API
and set of provider implementations, etc.  Process is context and Service
is function, which is also an important distinction with consideration to
Security.

Expanding on this concept, the Configuration Service could also be charged
with providing/serving the current configuration (not just recording it),
and both the Configuration Service and Management Service could be grouped
together as part of a larger, composite service, like an Administrative
Service, since both are indeed related functions to a certain degree.

Food for thought,

-j



On Wed, Feb 21, 2018 at 2:57 PM, Jens Deppe <jd...@pivotal.io> wrote:

> One thing that prompted this initial proposal is that our (management and
> monitoring) service boundaries, (or one could say APIs), are not well
> defined.
>
> Case in point; we currently have a 'configuration service' which is used to
> persist configuration. This service is only available on locators. The
> 'management service' (as defined/used by gfsh to manipulate configuration)
> can exist on both locators and servers. If it runs on servers then it
> suddenly does not have access to the configuration service.
>
> It almost feels like we need more capabilities around
> distributed/discoverable micro-services inside Geode.
>
> --Jens
>
> On Wed, Feb 21, 2018 at 10:44 AM, John Blum <jb...@pivotal.io> wrote:
>
> > Typo; Sorry!
> >
> > This..
> >
> > > 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*.
> >
> > should have read...
> >
> > > I may even launch and connect additional servers *within my IDE* (or
> > using
> >  *Gfsh*) that are connected to my *Boot* server, particularly if that
> > *Boot*
> >  server also embeds a *Locator*.
> >
> >
> > On Wed, Feb 21, 2018 at 10:25 AM, Kirk Lund <kl...@apache.org> wrote:
> >
> > > Most of the geode developers are working to get rid of singleton calls
> > (and
> > > next up static code) with the goal of being able to have multiple Cache
> > > instances in one JVM. This is to facilitate writing geode and geode
> > > application tests in one JVM. This fits in with what John is saying as
> > > well.
> > >
> > > Basically, don't make any changes that are going to make testing more
> > > difficult or prevent running everything in geode within one JVM.
> > >
> > > On Wed, Feb 21, 2018 at 10:12 AM, John Blum <jb...@pivotal.io> wrote:
> > >
> > > > 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 <ji...@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 <jb...@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)
> > > >
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>



-- 
-John
john.blum10101 (skype)

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[Jens Deppe <jd...@pivotal.io>]

One thing that prompted this initial proposal is that our (management and
monitoring) service boundaries, (or one could say APIs), are not well
defined.

Case in point; we currently have a 'configuration service' which is used to
persist configuration. This service is only available on locators. The
'management service' (as defined/used by gfsh to manipulate configuration)
can exist on both locators and servers. If it runs on servers then it
suddenly does not have access to the configuration service.

It almost feels like we need more capabilities around
distributed/discoverable micro-services inside Geode.

--Jens

On Wed, Feb 21, 2018 at 10:44 AM, John Blum <jb...@pivotal.io> wrote:

> Typo; Sorry!
>
> This..
>
> > 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*.
>
> should have read...
>
> > I may even launch and connect additional servers *within my IDE* (or
> using
>  *Gfsh*) that are connected to my *Boot* server, particularly if that
> *Boot*
>  server also embeds a *Locator*.
>
>
> On Wed, Feb 21, 2018 at 10:25 AM, Kirk Lund <kl...@apache.org> wrote:
>
> > Most of the geode developers are working to get rid of singleton calls
> (and
> > next up static code) with the goal of being able to have multiple Cache
> > instances in one JVM. This is to facilitate writing geode and geode
> > application tests in one JVM. This fits in with what John is saying as
> > well.
> >
> > Basically, don't make any changes that are going to make testing more
> > difficult or prevent running everything in geode within one JVM.
> >
> > On Wed, Feb 21, 2018 at 10:12 AM, John Blum <jb...@pivotal.io> wrote:
> >
> > > 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 <ji...@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 <jb...@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)
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[John Blum <jb...@pivotal.io>]

Typo; Sorry!

This..

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

should have read...

> I may even launch and connect additional servers *within my IDE* (or using
 *Gfsh*) that are connected to my *Boot* server, particularly if that *Boot*
 server also embeds a *Locator*.


On Wed, Feb 21, 2018 at 10:25 AM, Kirk Lund <kl...@apache.org> wrote:

> Most of the geode developers are working to get rid of singleton calls (and
> next up static code) with the goal of being able to have multiple Cache
> instances in one JVM. This is to facilitate writing geode and geode
> application tests in one JVM. This fits in with what John is saying as
> well.
>
> Basically, don't make any changes that are going to make testing more
> difficult or prevent running everything in geode within one JVM.
>
> On Wed, Feb 21, 2018 at 10:12 AM, John Blum <jb...@pivotal.io> wrote:
>
> > 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 <ji...@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 <jb...@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)
> >
>



-- 
-John
john.blum10101 (skype)

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[Kirk Lund <kl...@apache.org>]

Most of the geode developers are working to get rid of singleton calls (and
next up static code) with the goal of being able to have multiple Cache
instances in one JVM. This is to facilitate writing geode and geode
application tests in one JVM. This fits in with what John is saying as well.

Basically, don't make any changes that are going to make testing more
difficult or prevent running everything in geode within one JVM.

On Wed, Feb 21, 2018 at 10:12 AM, John Blum <jb...@pivotal.io> wrote:

> 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 <ji...@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 <jb...@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)
>

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[John Blum <jb...@pivotal.io>]

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 <ji...@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 <jb...@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)

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[Jinmei Liao <ji...@pivotal.io>]

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

Re: [PROPOSAL] Deprecate running JMX Manager on non-locator members

[John Blum <jb...@pivotal.io>]

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