Bruce- Regarding...
> "... *but it's the AcceptorImpl thread that keeps the JVM from exiting, so I don't really agree that you can create a server with gfsh that doesn't have a CacheServer.*" Well, that is not entirely true, and the last bit is definitely not true. How do you suppose I can do this... gfsh>start server --name=Server1 gfsh>start server --name=Server2 *--server-port*=51515 gfsh>start server --name=Server3 *--disable-default-port* gfsh>start server --name=Server4 *--disable-default-port* ... if I could not disable the CacheServer? Clearly, Server1 starts up with the default CacheServer port, 40404. Server2 explicitly sets the CacheServer port to 51515. And Servers 3 & 4 simply do not have CacheServers running. If they tried to start a CacheServer, and they did NOT explicitly set the --server-port option, then Servers 3 & 4 would result in throwing a java.net.BindException. So, the ServerLauncher class "blocks" if you do not start a CacheServer instance, which would not be started if the server was started using `start server --disable-default-server`). See here [1], then here [2], and then here [3] and here [4] as well as this [5], which gets set from this [6]. There is a very good reason why I know this. Regards, -John [1] https://github.com/apache/geode/blob/rel/v1.7.0/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L705 [2] https://github.com/apache/geode/blob/rel/v1.7.0/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L906-L928 [3] https://github.com/apache/geode/blob/rel/v1.7.0/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L953 [4] https://github.com/apache/geode/blob/rel/v1.7.0/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L940-L942 [5] https://github.com/apache/geode/blob/rel/v1.7.0/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L407-L409 [6] https://github.com/apache/geode/blob/rel/v1.7.0/geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L1487 On Fri, Nov 2, 2018 at 3:03 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > Hmm, but it's the AcceptorImpl thread that keeps the JVM from exiting, so > I don't really agree that you can create a server with gfsh that doesn't > have a CacheServer. One's got to be created through cache.xml or something. > > Be that as it may I think the recent talk about this convinces me that > Kirk's original proposal is sound and we should go with it. Servers can be > fished out of the cache so it's not a big deal if the launcher API doesn't > have a getCacheServer method. > > > On 11/1/18 9:38 AM, John Blum wrote: > >> Well, ServerLauncher may or may not create a CacheServer instance when it >> starts a server. A server can be created without a CacheServer, for >> instance, when in *Gfsh* `start server --disable-default-server` option is >> >> specified. >> >> In addition, you can always find or get the list of CacheServers (if >> present) from the Cache instance, using >> Cache.getCacheServers():List<CacheServer> [1]. So, I think it would be >> better if the ServerLauncher returned a handle to the Cache and then drill >> down as opposed to up. >> >> -j >> >> >> [1] >> http://geode.apache.org/releases/latest/javadoc/org/apache/ >> geode/cache/Cache.html#getCacheServers-- >> >> >> On Thu, Nov 1, 2018 at 7:31 AM, Bruce Schuchardt <bschucha...@pivotal.io> >> wrote: >> >> I like this but it might be even better if ServerLauncher gave access to >>> the CacheServer it launched and CacheServer gave access to its cache. >>> The >>> Locator interface, as well, could have a getCache() method and deprecate >>> the getDistributedSystem() method. These days a Locator always has a >>> Cache >>> and no-one is interested in its DistributedSystem. >>> >>> >>> On 10/31/18 2:48 PM, Kirk Lund wrote: >>> >>> LocatorLauncher provides an API which can be used in-process to create a >>>> Locator. There is no public API on that class to get a reference to the >>>> Locator or its Cache. >>>> >>>> Similarly, ServerLauncher provides an API which can be used in-process >>>> to >>>> create a Server, but there is no public API in that class to get a >>>> reference to its Cache. >>>> >>>> The User of either Launcher would then have to resort to invoking >>>> singletons to get a reference to the Cache. >>>> >>>> There are existing package-private getter APIs on both Launchers but >>>> they're only used by tests in that same package. >>>> >>>> I propose adding public APIs for getCache to both LocatorLauncher and >>>> ServerLauncher as well as adding getLocator to LocatorLauncher. The >>>> signatures would look like: >>>> >>>> /** >>>> * Gets a reference to the Cache that was created by this >>>> ServerLauncher. >>>> * >>>> * @return a reference to the Cache >>>> */ >>>> public org.apache.geode.cache.Cache getCache(); >>>> >>>> /** >>>> * Gets a reference to the Locator that was created by this >>>> LocatorLauncher. >>>> * >>>> * @return a reference to the Locator >>>> */ >>>> public org.apache.geode.distributed.Locator getLocator(); >>>> >>>> Any thoughts? Yay or nay? >>>> >>>> Thanks, >>>> Kirk >>>> >>>> >>>> >> > -- -John john.blum10101 (skype)
