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)

Reply via email to