You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2018/10/31 21:48:04 UTC
[PROPOSAL] Add getCache and getLocator to Launchers
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
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Bill Burcham <bb...@pivotal.io>.
+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 the cache via getCache() themselves. Would it make sense to
expose getLocator() on LocatorLauncher instances (instead of exposing
getCache() on those)?
If we did implement getCache() for LocatorLauncher instances, it might look
something like this:
// on LocatorLauncher
public Optional<Cache> getCache() {
return locator == null ? Optional.empty() :
Optional.of(locator.getCache());
}
That traversal seems more appropriate for the caller to implement. That way
the caller knows why the cache is unavailable (when its unavailable) e.g.
because there is no locator vs. because there is a locator but that locator
has no cache.
On Wed, Oct 31, 2018 at 3:05 PM Dan Smith <ds...@pivotal.io> wrote:
> Yay for APIs that don't require singletons!
>
> -Dan
>
> On Wed, Oct 31, 2018 at 2:54 PM Jinmei Liao <ji...@pivotal.io> 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 <kl...@apache.org> 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
> > >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Dan Smith <ds...@pivotal.io>.
Yay for APIs that don't require singletons!
-Dan
On Wed, Oct 31, 2018 at 2:54 PM Jinmei Liao <ji...@pivotal.io> 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 <kl...@apache.org> 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
> >
>
>
> --
> Cheers
>
> Jinmei
>
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Jinmei Liao <ji...@pivotal.io>.
+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 <kl...@apache.org> 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
>
--
Cheers
Jinmei
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Galen O'Sullivan <go...@pivotal.io>.
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 <jb...@pivotal.io> 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 <bs...@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)
>
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 10.99.199.7[*40404*] as
> Server1 is currently online.
> Process ID: 49850
> Uptime: 3 seconds
> Geode Version: 1.6.0
> Java Version: 1.8.0_192
> Log File: /Users/jblum/pivdev/lab/Server1/Server1.log
> JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
>
>
>
> gfsh>show log --member=*Server1* --lines=20
> SystemLog:
>
> [info 2018/11/02 17:52:53.523 PDT Server1 <main> tid=0x1] Initialization of
> region _monitoringRegion_10.99.199.7<v1>1025 completed
>
> [info 2018/11/02 17:52:54.146 PDT Server1 <main> tid=0x1] Initialized cache
> service org.apache.geode.connectors.jdbc.internal.JdbcConnectorServiceImpl
>
> [info 2018/11/02 17:52:54.160 PDT Server1 <main> tid=0x1] Initialized cache
> service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
>
> [info 2018/11/02 17:52:54.161 PDT Server1 <main> tid=0x1] Initialized cache
> service com.gemstone.gemfire.OldClientSupportProvider
>
> [info 2018/11/02 17:52:54.171 PDT Server1 <main> tid=0x1] Initializing
> region PdxTypes
>
> [info 2018/11/02 17:52:54.173 PDT Server1 <main> tid=0x1] Initialization of
> region PdxTypes completed
>
> [info 2018/11/02 17:52:54.226 PDT Server1 <main> tid=0x1] Cache server
> connection listener bound to address 10.99.199.7-0.0.0.0/0.0.0.0:40404 with
> backlog 1,000.
>
> [info 2018/11/02 17:52:54.235 PDT Server1 <main> tid=0x1]
> ClientHealthMonitorThread maximum allowed time between pings: 60,000
>
> [warning 2018/11/02 17:52:54.236 PDT Server1 <main> tid=0x1] Handshaker max
> Pool size: 4
>
> [info 2018/11/02 17:52:54.242 PDT *Server1* <main> tid=0x1] *CacheServer
> Configuration: port=40404* max-connections=800 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
> maximum-time-between-pings=60000 maximum-message-count=230000
> message-time-to-live=180 eviction-policy=none capacity=1 overflow
> directory=. groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000
> tcpNoDelay=true
>
>
>
> gfsh>start server --name=*Server2* --log-level=config --server-port=51515
> Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
> ...
> Server in /Users/jblum/pivdev/lab/Server2 on 10.99.199.7[*51515*] as
> Server2 is currently online.
> Process ID: 49916
> Uptime: 3 seconds
> Geode Version: 1.6.0
> Java Version: 1.8.0_192
> Log File: /Users/jblum/pivdev/lab/Server2/Server2.log
> JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
>
>
>
> gfsh>show log --member=Server2 --lines=20
> SystemLog:
>
> [info 2018/11/02 17:54:36.776 PDT Server2 <main> tid=0x1] Initialized cache
> service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
>
> [info 2018/11/02 17:54:36.777 PDT Server2 <main> tid=0x1] Initialized cache
> service com.gemstone.gemfire.OldClientSupportProvider
>
> [info 2018/11/02 17:54:36.788 PDT Server2 <main> tid=0x1] Initializing
> region PdxTypes
>
> [info 2018/11/02 17:54:36.793 PDT Server2 <main> tid=0x1] Region PdxTypes
> requesting initial image from 10.99.199.7(Server1:49850)<v1>:1025
>
> [info 2018/11/02 17:54:36.797 PDT Server2 <main> tid=0x1] PdxTypes is done
> getting image from 10.99.199.7(Server1:49850)<v1>:1025. isDeltaGII is false
>
> [info 2018/11/02 17:54:36.797 PDT Server2 <main> tid=0x1] Initialization of
> region PdxTypes completed
>
> [info 2018/11/02 17:54:36.852 PDT Server2 <main> tid=0x1] Cache server
> connection listener bound to address 10.99.199.7-0.0.0.0/0.0.0.0:51515 with
> backlog 1,000.
>
> [info 2018/11/02 17:54:36.859 PDT Server2 <main> tid=0x1]
> ClientHealthMonitorThread maximum allowed time between pings: 60,000
>
> [warning 2018/11/02 17:54:36.860 PDT Server2 <main> tid=0x1] Handshaker max
> Pool size: 4
>
> [info 2018/11/02 17:54:36.867 PDT *Server2* <main> tid=0x1] *CacheServer
> Configuration: port=51515* max-connections=800 max-threads=0
> notify-by-subscription=true socket-buffer-size=32768
> maximum-time-between-pings=60000 maximum-message-count=230000
> message-time-to-live=180 eviction-policy=none capacity=1 overflow
> directory=. groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000
> tcpNoDelay=true
>
>
>
> gfsh>start server --name=*Server3* --log-level=config
> --disable-default-server
> Starting a Geode Server in /Users/jblum/pivdev/lab/Server3...
> ....
> Server in /Users/jblum/pivdev/lab/Server3 on 10.99.199.7 as Server3 is
> currently online.
> Process ID: 49955
> Uptime: 3 seconds
> Geode Version: 1.6.0
> Java Version: 1.8.0_192
> Log File: /Users/jblum/pivdev/lab/Server3/Server3.log
> JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
>
>
>
> gfsh>show log --member=*Server3* --lines=20
> SystemLog:
>
> [info 2018/11/02 17:55:19.144 PDT Server3 <main> tid=0x1] Region
> _monitoringRegion_10.99.199.7<v3>1027 requesting initial image from
> 10.99.199.7(Locator1:49705:locator)<ec><v0>:1024
>
> [info 2018/11/02 17:55:19.147 PDT Server3 <main> tid=0x1]
> _monitoringRegion_10.99.199.7<v3>1027 is done getting image from
> 10.99.199.7(Locator1:49705:locator)<ec><v0>:1024. isDeltaGII is false
>
> [info 2018/11/02 17:55:19.147 PDT Server3 <main> tid=0x1] Initialization of
> region _monitoringRegion_10.99.199.7<v3>1027 completed
>
> [info 2018/11/02 17:55:19.811 PDT Server3 <main> tid=0x1] Initialized cache
> service org.apache.geode.connectors.jdbc.internal.JdbcConnectorServiceImpl
>
> [info 2018/11/02 17:55:19.823 PDT Server3 <main> tid=0x1] Initialized cache
> service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
>
> [info 2018/11/02 17:55:19.824 PDT Server3 <main> tid=0x1] Initialized cache
> service com.gemstone.gemfire.OldClientSupportProvider
>
> [info 2018/11/02 17:55:19.834 PDT Server3 <main> tid=0x1] Initializing
> region PdxTypes
>
> [info 2018/11/02 17:55:19.842 PDT Server3 <main> tid=0x1] Region PdxTypes
> requesting initial image from 10.99.199.7(Server2:49916)<v2>:1026
>
> [info 2018/11/02 17:55:19.846 PDT Server3 <main> tid=0x1] PdxTypes is done
> getting image from 10.99.199.7(Server2:49916)<v2>:1026. isDeltaGII is false
>
> [info 2018/11/02 17:55:19.846 PDT Server3 <main> tid=0x1] Initialization of
> region PdxTypes completed
>
>
>
> gfsh>start server --name=*Server4* --log-level=config
> --disable-default-server
> Starting a Geode Server in /Users/jblum/pivdev/lab/Server4...
> ....
> Server in /Users/jblum/pivdev/lab/Server4 on 10.99.199.7 as Server4 is
> currently online.
> Process ID: 49972
> Uptime: 3 seconds
> Geode Version: 1.6.0
> Java Version: 1.8.0_192
> Log File: /Users/jblum/pivdev/lab/Server4/Server4.log
> JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
>
>
>
> gfsh>show log --member=*Server4* --lines=20
> SystemLog:
>
> [info 2018/11/02 17:55:48.826 PDT Server4 <main> tid=0x1] Region
> _monitoringRegion_10.99.199.7<v4>1028 requesting initial image from
> 10.99.199.7(Locator1:49705:locator)<ec><v0>:1024
>
> [info 2018/11/02 17:55:48.829 PDT Server4 <main> tid=0x1]
> _monitoringRegion_10.99.199.7<v4>1028 is done getting image from
> 10.99.199.7(Locator1:49705:locator)<ec><v0>:1024. isDeltaGII is false
>
> [info 2018/11/02 17:55:48.829 PDT Server4 <main> tid=0x1] Initialization of
> region _monitoringRegion_10.99.199.7<v4>1028 completed
>
> [info 2018/11/02 17:55:49.475 PDT Server4 <main> tid=0x1] Initialized cache
> service org.apache.geode.connectors.jdbc.internal.JdbcConnectorServiceImpl
>
> [info 2018/11/02 17:55:49.489 PDT Server4 <main> tid=0x1] Initialized cache
> service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
>
> [info 2018/11/02 17:55:49.499 PDT Server4 <main> tid=0x1] Initialized cache
> service com.gemstone.gemfire.OldClientSupportProvider
>
> [info 2018/11/02 17:55:49.509 PDT Server4 <main> tid=0x1] Initializing
> region PdxTypes
>
> [info 2018/11/02 17:55:49.517 PDT Server4 <main> tid=0x1] Region PdxTypes
> requesting initial image from 10.99.199.7(Server3:49955)<v3>:1027
>
> [info 2018/11/02 17:55:49.521 PDT Server4 <main> tid=0x1] PdxTypes is done
> getting image from 10.99.199.7(Server3:49955)<v3>:1027. isDeltaGII is false
>
> [info 2018/11/02 17:55:49.521 PDT Server4 <main> tid=0x1] Initialization of
> region PdxTypes completed
>
>
>
> gfsh>list members
> Name | Id
> -------- | --------------------------------------------------------------
> Locator1 | 10.99.199.7(Locator1:49705:locator)<ec><v0>:1024 [Coordinator]
> Server1 | 10.99.199.7(Server1:49850)<v1>:1025
> Server2 | 10.99.199.7(Server2:49916)<v2>:1026
> Server3 | 10.99.199.7(Server3:49955)<v3>:1027
> Server4 | 10.99.199.7(Server4:49972)<v4>:1028
>
>
>
> However, if I not started Server5 using the default port (i.e. *40404*) or
> mistakenly tried to reuse port 51515, then I would get...
>
>
>
> gfsh>debug --state=ON
> Debug is ON
>
>
>
> gfsh>start server --name=*Server5* --log-level=config
> /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre/bin/java
> -server -classpath
> /Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
> -Dgemfire.default.locators=10.99.199.7[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> org.apache.geode.distributed.ServerLauncher start Server5 --debug
> --server-port=40404
> Starting a Geode Server in /Users/jblum/pivdev/lab/Server5...
> The Cache Server process terminated unexpectedly with exit status 1. Please
> refer to the log file in /Users/jblum/pivdev/lab/Server5 for full details.
>
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> while starting a Server in /Users/jblum/pivdev/lab/Server5 on
> 10.99.199.7[40404]: Network is unreachable; port (40404) is not available
> on localhost.
>
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:804)
>
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
>
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
>
> Caused by: *java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost.*
>
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:129)
>
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:749)
>
> ... 2 more
>
>
> Cheers,
> -John
>
>
>
> On Fri, Nov 2, 2018 at 5:49 PM, John Blum <jb...@pivotal.io> wrote:
>
>> 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 <jb...@pivotal.io> wrote:
>>
>>> 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-co
>>> re/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L705
>>> [2] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>>> re/src/main/java/org/apache/geode/distributed/ServerLauncher
>>> .java#L906-L928
>>> [3] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>>> re/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L953
>>> [4] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>>> re/src/main/java/org/apache/geode/distributed/ServerLauncher
>>> .java#L940-L942
>>> [5] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>>> re/src/main/java/org/apache/geode/distributed/ServerLauncher
>>> .java#L407-L409
>>> [6] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>>> re/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L1487
>>>
>>>
>>> On Fri, Nov 2, 2018 at 3:03 PM, Bruce Schuchardt <bs...@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/g
>>>>> eode/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
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>> --
>>> -John
>>> john.blum10101 (skype)
>>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by John Blum <jb...@pivotal.io>.
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: 49850
Uptime: 3 seconds
Geode Version: 1.6.0
Java Version: 1.8.0_192
Log File: /Users/jblum/pivdev/lab/Server1/Server1.log
JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
-Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
-Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
gfsh>show log --member=*Server1* --lines=20
SystemLog:
[info 2018/11/02 17:52:53.523 PDT Server1 <main> tid=0x1] Initialization of
region _monitoringRegion_10.99.199.7<v1>1025 completed
[info 2018/11/02 17:52:54.146 PDT Server1 <main> tid=0x1] Initialized cache
service org.apache.geode.connectors.jdbc.internal.JdbcConnectorServiceImpl
[info 2018/11/02 17:52:54.160 PDT Server1 <main> tid=0x1] Initialized cache
service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
[info 2018/11/02 17:52:54.161 PDT Server1 <main> tid=0x1] Initialized cache
service com.gemstone.gemfire.OldClientSupportProvider
[info 2018/11/02 17:52:54.171 PDT Server1 <main> tid=0x1] Initializing
region PdxTypes
[info 2018/11/02 17:52:54.173 PDT Server1 <main> tid=0x1] Initialization of
region PdxTypes completed
[info 2018/11/02 17:52:54.226 PDT Server1 <main> tid=0x1] Cache server
connection listener bound to address 10.99.199.7-0.0.0.0/0.0.0.0:40404 with
backlog 1,000.
[info 2018/11/02 17:52:54.235 PDT Server1 <main> tid=0x1]
ClientHealthMonitorThread maximum allowed time between pings: 60,000
[warning 2018/11/02 17:52:54.236 PDT Server1 <main> tid=0x1] Handshaker max
Pool size: 4
[info 2018/11/02 17:52:54.242 PDT *Server1* <main> tid=0x1] *CacheServer
Configuration: port=40404* max-connections=800 max-threads=0
notify-by-subscription=true socket-buffer-size=32768
maximum-time-between-pings=60000 maximum-message-count=230000
message-time-to-live=180 eviction-policy=none capacity=1 overflow
directory=. groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000
tcpNoDelay=true
gfsh>start server --name=*Server2* --log-level=config --server-port=51515
Starting a Geode Server in /Users/jblum/pivdev/lab/Server2...
...
Server in /Users/jblum/pivdev/lab/Server2 on 10.99.199.7[*51515*] as
Server2 is currently online.
Process ID: 49916
Uptime: 3 seconds
Geode Version: 1.6.0
Java Version: 1.8.0_192
Log File: /Users/jblum/pivdev/lab/Server2/Server2.log
JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
-Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
-Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
gfsh>show log --member=Server2 --lines=20
SystemLog:
[info 2018/11/02 17:54:36.776 PDT Server2 <main> tid=0x1] Initialized cache
service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
[info 2018/11/02 17:54:36.777 PDT Server2 <main> tid=0x1] Initialized cache
service com.gemstone.gemfire.OldClientSupportProvider
[info 2018/11/02 17:54:36.788 PDT Server2 <main> tid=0x1] Initializing
region PdxTypes
[info 2018/11/02 17:54:36.793 PDT Server2 <main> tid=0x1] Region PdxTypes
requesting initial image from 10.99.199.7(Server1:49850)<v1>:1025
[info 2018/11/02 17:54:36.797 PDT Server2 <main> tid=0x1] PdxTypes is done
getting image from 10.99.199.7(Server1:49850)<v1>:1025. isDeltaGII is false
[info 2018/11/02 17:54:36.797 PDT Server2 <main> tid=0x1] Initialization of
region PdxTypes completed
[info 2018/11/02 17:54:36.852 PDT Server2 <main> tid=0x1] Cache server
connection listener bound to address 10.99.199.7-0.0.0.0/0.0.0.0:51515 with
backlog 1,000.
[info 2018/11/02 17:54:36.859 PDT Server2 <main> tid=0x1]
ClientHealthMonitorThread maximum allowed time between pings: 60,000
[warning 2018/11/02 17:54:36.860 PDT Server2 <main> tid=0x1] Handshaker max
Pool size: 4
[info 2018/11/02 17:54:36.867 PDT *Server2* <main> tid=0x1] *CacheServer
Configuration: port=51515* max-connections=800 max-threads=0
notify-by-subscription=true socket-buffer-size=32768
maximum-time-between-pings=60000 maximum-message-count=230000
message-time-to-live=180 eviction-policy=none capacity=1 overflow
directory=. groups=[] loadProbe=ConnectionCountProbe loadPollInterval=5000
tcpNoDelay=true
gfsh>start server --name=*Server3* --log-level=config
--disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server3...
....
Server in /Users/jblum/pivdev/lab/Server3 on 10.99.199.7 as Server3 is
currently online.
Process ID: 49955
Uptime: 3 seconds
Geode Version: 1.6.0
Java Version: 1.8.0_192
Log File: /Users/jblum/pivdev/lab/Server3/Server3.log
JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
-Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
-Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
gfsh>show log --member=*Server3* --lines=20
SystemLog:
[info 2018/11/02 17:55:19.144 PDT Server3 <main> tid=0x1] Region
_monitoringRegion_10.99.199.7<v3>1027 requesting initial image from
10.99.199.7(Locator1:49705:locator)<ec><v0>:1024
[info 2018/11/02 17:55:19.147 PDT Server3 <main> tid=0x1]
_monitoringRegion_10.99.199.7<v3>1027 is done getting image from
10.99.199.7(Locator1:49705:locator)<ec><v0>:1024. isDeltaGII is false
[info 2018/11/02 17:55:19.147 PDT Server3 <main> tid=0x1] Initialization of
region _monitoringRegion_10.99.199.7<v3>1027 completed
[info 2018/11/02 17:55:19.811 PDT Server3 <main> tid=0x1] Initialized cache
service org.apache.geode.connectors.jdbc.internal.JdbcConnectorServiceImpl
[info 2018/11/02 17:55:19.823 PDT Server3 <main> tid=0x1] Initialized cache
service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
[info 2018/11/02 17:55:19.824 PDT Server3 <main> tid=0x1] Initialized cache
service com.gemstone.gemfire.OldClientSupportProvider
[info 2018/11/02 17:55:19.834 PDT Server3 <main> tid=0x1] Initializing
region PdxTypes
[info 2018/11/02 17:55:19.842 PDT Server3 <main> tid=0x1] Region PdxTypes
requesting initial image from 10.99.199.7(Server2:49916)<v2>:1026
[info 2018/11/02 17:55:19.846 PDT Server3 <main> tid=0x1] PdxTypes is done
getting image from 10.99.199.7(Server2:49916)<v2>:1026. isDeltaGII is false
[info 2018/11/02 17:55:19.846 PDT Server3 <main> tid=0x1] Initialization of
region PdxTypes completed
gfsh>start server --name=*Server4* --log-level=config
--disable-default-server
Starting a Geode Server in /Users/jblum/pivdev/lab/Server4...
....
Server in /Users/jblum/pivdev/lab/Server4 on 10.99.199.7 as Server4 is
currently online.
Process ID: 49972
Uptime: 3 seconds
Geode Version: 1.6.0
Java Version: 1.8.0_192
Log File: /Users/jblum/pivdev/lab/Server4/Server4.log
JVM Arguments: -Dgemfire.default.locators=10.99.199.7[10334]
-Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
-Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
gfsh>show log --member=*Server4* --lines=20
SystemLog:
[info 2018/11/02 17:55:48.826 PDT Server4 <main> tid=0x1] Region
_monitoringRegion_10.99.199.7<v4>1028 requesting initial image from
10.99.199.7(Locator1:49705:locator)<ec><v0>:1024
[info 2018/11/02 17:55:48.829 PDT Server4 <main> tid=0x1]
_monitoringRegion_10.99.199.7<v4>1028 is done getting image from
10.99.199.7(Locator1:49705:locator)<ec><v0>:1024. isDeltaGII is false
[info 2018/11/02 17:55:48.829 PDT Server4 <main> tid=0x1] Initialization of
region _monitoringRegion_10.99.199.7<v4>1028 completed
[info 2018/11/02 17:55:49.475 PDT Server4 <main> tid=0x1] Initialized cache
service org.apache.geode.connectors.jdbc.internal.JdbcConnectorServiceImpl
[info 2018/11/02 17:55:49.489 PDT Server4 <main> tid=0x1] Initialized cache
service org.apache.geode.cache.lucene.internal.LuceneServiceImpl
[info 2018/11/02 17:55:49.499 PDT Server4 <main> tid=0x1] Initialized cache
service com.gemstone.gemfire.OldClientSupportProvider
[info 2018/11/02 17:55:49.509 PDT Server4 <main> tid=0x1] Initializing
region PdxTypes
[info 2018/11/02 17:55:49.517 PDT Server4 <main> tid=0x1] Region PdxTypes
requesting initial image from 10.99.199.7(Server3:49955)<v3>:1027
[info 2018/11/02 17:55:49.521 PDT Server4 <main> tid=0x1] PdxTypes is done
getting image from 10.99.199.7(Server3:49955)<v3>:1027. isDeltaGII is false
[info 2018/11/02 17:55:49.521 PDT Server4 <main> tid=0x1] Initialization of
region PdxTypes completed
gfsh>list members
Name | Id
-------- | --------------------------------------------------------------
Locator1 | 10.99.199.7(Locator1:49705:locator)<ec><v0>:1024 [Coordinator]
Server1 | 10.99.199.7(Server1:49850)<v1>:1025
Server2 | 10.99.199.7(Server2:49916)<v2>:1026
Server3 | 10.99.199.7(Server3:49955)<v3>:1027
Server4 | 10.99.199.7(Server4:49972)<v4>:1028
However, if I not started Server5 using the default port (i.e. *40404*) or
mistakenly tried to reuse port 51515, then I would get...
gfsh>debug --state=ON
Debug is ON
gfsh>start server --name=*Server5* --log-level=config
/Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre/bin/java
-server -classpath
/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-core-1.6.0.jar:/Users/jblum/pivdev/apache-geode-1.6.0/lib/geode-dependencies.jar
-Dgemfire.default.locators=10.99.199.7[10334]
-Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
-Dgemfire.log-level=config -XX:OnOutOfMemoryError=kill -KILL %p
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
org.apache.geode.distributed.ServerLauncher start Server5 --debug
--server-port=40404
Starting a Geode Server in /Users/jblum/pivdev/lab/Server5...
The Cache Server process terminated unexpectedly with exit status 1. Please
refer to the log file in /Users/jblum/pivdev/lab/Server5 for full details.
Exception in thread "main" java.lang.RuntimeException: An IO error occurred
while starting a Server in /Users/jblum/pivdev/lab/Server5 on
10.99.199.7[40404]: Network is unreachable; port (40404) is not available
on localhost.
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:804)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:225)
Caused by: *java.net.BindException: Network is unreachable; port (40404) is
not available on localhost.*
at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:129)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:749)
... 2 more
Cheers,
-John
On Fri, Nov 2, 2018 at 5:49 PM, John Blum <jb...@pivotal.io> wrote:
> 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 <jb...@pivotal.io> wrote:
>
>> 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-co
>> re/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L705
>> [2] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>> re/src/main/java/org/apache/geode/distributed/ServerLauncher
>> .java#L906-L928
>> [3] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>> re/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L953
>> [4] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>> re/src/main/java/org/apache/geode/distributed/ServerLauncher
>> .java#L940-L942
>> [5] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>> re/src/main/java/org/apache/geode/distributed/ServerLauncher
>> .java#L407-L409
>> [6] https://github.com/apache/geode/blob/rel/v1.7.0/geode-co
>> re/src/main/java/org/apache/geode/distributed/ServerLauncher.java#L1487
>>
>>
>> On Fri, Nov 2, 2018 at 3:03 PM, Bruce Schuchardt <bs...@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/g
>>>> eode/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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
>
> --
> -John
> john.blum10101 (skype)
>
--
-John
john.blum10101 (skype)
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by John Blum <jb...@pivotal.io>.
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 <jb...@pivotal.io> wrote:
> 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 <bs...@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/g
>>> eode/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
>>>>>
>>>>>
>>>>>
>>>
>>
>
>
> --
> -John
> john.blum10101 (skype)
>
--
-John
john.blum10101 (skype)
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by John Blum <jb...@pivotal.io>.
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 <bs...@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 <bs...@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)
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Kirk Lund <kl...@apache.org>.
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 <bs...@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 <bs...@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
>>>>
>>>>
>>>>
>>
>
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <bs...@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
>>>
>>>
>
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by John Blum <jb...@pivotal.io>.
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 <bs...@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)
Re: [PROPOSAL] Add getCache and getLocator to Launchers
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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
>