Here is a bit more detail on Darrel's third paragraph: When a CacheServer is created, it exchanges profiles with the locator.
The CacheServer's profile (an instance of BridgeServerProfile) contains among other things the host. The host is determined using BridgeServerImpl.getExternalAddress which uses: - hostnameForClients (from cache-server hostname-for-clients attribute) - bindAddress (from either cache-server bind-address attribute or Geode bind-address property) - canonical host name One interesting thing is the getExternalAddress method contains a test to see if the CacheServer's connection listener is listening on any local address in the case where bind-address is set. If that test passes, the canonical host name is returned instead of the bind-address. I'm not sure how the bind-address can be set and the connection listener can be listening on all local addresses, though. When a cache server connection listener is established, it listens on all local addresses by default: [info 2015/07/01 17:35:14.788 PDT <main> tid=0x1] Bridge server connection listener bound to address 0.0.0.0/0.0.0.0:40404 with backlog 1,000. If the bind-address is set, then it listens on just that address: [info 2015/07/01 17:30:56.292 PDT <main> tid=0x1] Bridge server connection listener bound to address /xxx.xxx.x.xx:40404 with backlog 1,000. Based on that test, there must be a case where setting the bind-address still causes the connection listener to listen on all local addresses. Barry Oglesby GemFire Advanced Customer Engineering (ACE) For immediate support please contact Pivotal Support at http://support.pivotal.io/ On Wed, Jul 1, 2015 at 9:55 AM, Darrel Schneider <[email protected]> wrote: > My answers are based on the java client/server but I think they are also > true for the native client. > All connections between the client and server are initiated by the client. > > If the client has subscriptions then a dedicated connection is made for all > its subscription messages that are pushed to it by the server. For > operations that are initiated on a client it will have at least one other > connection to the server. How many of these you end up with are controlled > by the connection pool configuration and how many concurrent threads are > doing ops in the client. > > If your server binds to a ip address (instead of a host name) then I think > that ip address will be sent to the clients by that locator. I have not > tested this and it is possible we do a reverse lookup and end up sending a > host name for the server bind ip address. > > However we also have a server hostname-for-clients that can be specified > and you can configure it to be an ip address and that ip address will be > sent by the locator to the clients and then used by the client to connect > to the server. > > > On Wed, Jul 1, 2015 at 9:04 AM, Michael Stolz <[email protected]> wrote: > > > I have always wondered how exactly the connections between the clients > and > > Cache Servers work under the covers. > > > > I believe I have heard that there are 2 connections minimum between a > > CacheServer and a client, one for get/put, etc request/reply type traffic > > and a separate one for subscription type traffic. > > > > If that is true my next question is, do both of those connections get > > initiated from the client side? > > > > Last question, are the hostnames given to the client by the locator in > the > > form of 192.168.1.1 TCP/IP numerical addresses or are they host names? In > > the particular case of a big compute grid with thousands of nodes it > would > > be better if we gave them our numerical addresses to avoid 1000 > > simultaneous DNS lookups. Can that be arranged? > > > > -- > > Mike Stolz > > Principal Technical Account Manager > > Mobile: 631-835-4771 > > >
