Cool - okay, I'm convinced
On 11/2/18 6:02 PM, John Blum wrote:
To make this example a bit more concrete for everyone else...
gfsh>start server --name=*Server1* --log-level=config
Starting a Geode Server in /Users/jblum/pivdev/lab/Server1...
Server in /Users/jblum/pivdev/lab/Server1 on
To make this example a bit more concrete for everyone else...
gfsh>start server --name=*Server1* --log-level=config
Starting a Geode Server in /Users/jblum/pivdev/lab/Server1...
Server in /Users/jblum/pivdev/lab/Server1 on 10.99.199.7[*40404*] as
Server1 is currently online.
Process ID: 498
Damn it! Correction to my previous email...
'--disable-default-port' should read '--disable-default-server' in my *Gfsh*
`start server` command examples.
Apologies,
John
On Fri, Nov 2, 2018 at 5:41 PM, John Blum wrote:
> Bruce-
>
> Regarding...
>
> > "... *but it's the AcceptorImpl thread tha
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 t
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=0x7ff1f4006800 nid=0x1c03 in
Object.wait() [0x7d906000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lan
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
I'm with Bill and John on this one. Give the top-level object only and let
users move down the object heirarchy.
On Thu, Nov 1, 2018 at 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 Cache
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
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 Cach
+1 for exposing getCache() on CacheLauncher instances. Death to all
singletons!
I'm less certain about the wisdom of exposing a getCache() on
LocatorLauncher instances. Seems like it would be better to let clients
call getLocator() on LocatorLauncher instances, then they can do the
traversal to th
Yay for APIs that don't require singletons!
-Dan
On Wed, Oct 31, 2018 at 2:54 PM Jinmei Liao wrote:
> +1. sounds like a good addition and since we already have package level
> getters for them anyway.
>
> On Wed, Oct 31, 2018 at 2:48 PM Kirk Lund wrote:
>
> > LocatorLauncher provides an API wh
+1. sounds like a good addition and since we already have package level
getters for them anyway.
On Wed, Oct 31, 2018 at 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
>
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
13 matches
Mail list logo
