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
