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