geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: [PROPOSAL] Add getCache and getLocator to Launchers
Date Fri, 02 Nov 2018 23:28:25 GMT
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 <bschuchardt@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 <bschuchardt@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
>>>>
>>>>
>>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message