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 <jil...@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)
