It's not the AcceptorImpl thread -- it's actually the main thread in
ServerLauncher which keeps the JVM from exiting:
"main" #1 prio=5 os_prio=31 tid=0x00007ff1f4006800 nid=0x1c03 in
Object.wait() [0x000070000d906000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000006c001d948> (a
org.apache.geode.distributed.ServerLauncher)
at
org.apache.geode.distributed.ServerLauncher.waitOnServer(ServerLauncher.java:919)
- locked <0x00000006c001d948> (a
org.apache.geode.distributed.ServerLauncher)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:708)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:227)
If you issue a "stop server" request, then that will cause the main thread
to exit ServerLauncher.waitOnServer.
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
>>>>
>>>>
>>>>
>>
>
