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 <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) > > > -- -John john.blum10101 (skype)
