The Java API is still something that I am working on in order to finalize
but I it is great that you brought it up. Currently, there are two main
implementation of the Client interface, the ServerClient, and the
TransportClient. You are correct regarding the ServerClient, you should not
create a new instance of it yourself, but instead, use the Server#client()
method to get it.
The ServerClient is just an API to use when starting an embedded Server
(be it a data node or not). The Server instance starts a node, and that node
will be part of the cluster (it will get cluster events, and so on). Using
the API, you still work against the whole cluster, meaning that if you index
something, and it needs to get to another node to be indexed, then there
will be automatic routing. The benefit of using the ServerClient (or
starting a Server in your "client" Java application) is the fact that you
always do only one hop. For example, the index operation will perform the
routing and "hit" the correct node with the data.
The TransportClient is a dumb down Transport based client, where you add
addresses and it will connect to the nodes, discover through them the rest
of the nodes, and do dummy load balancing for each operation. This means
that when you index something, the transport client will peak node at
random, perform the index operation on it, and that node will do the
hashing and proper routing to the correct node.
You would probably always want to use ServerClient if you can, because of
the performance benefits (usually with node.data set to false, so it won't
hold any index information). But then it means that the client will be part
of the cluster. The question if you can do it or not is up to the Discovery
module that you choose to use (which, currently, is just JGroups). If you
have a client behind a firewall, then its more tricky to configure JGroups,
so you might as well use the TransportClient for simplicity. Another point
about JGroups is the fact that the client (even though it is not a data
node) might become the master of the cluster, which you might not want.
On Sat, Feb 20, 2010 at 9:27 AM, Lukas Vlcek email@example.com wrote:
I found there are three implementations of o.es.c.Client interface. I
would like to understand what is the difference. Please take a look at
the below findings and let me know if there is any miss-understanding,
So far I've learned that:
ServerClient - this is tied to a particular server instance and there
is always only one client for one server. I guess it should never be
instantiated (though it has public constructor) but it is the server
which is responsible to create and close this instance.
TransportClient - it can connect to one or more servers using port
number. JavaDoc says it is not part of the cloud, which I think means
that the purpose of this class is to connect to server(s) via net
whereas the ServerClient talks to server directly (kind of embedded
InternalTransportClient - used internally by TransportClient only. So
there is no practical use case for this implementation (other then it
is used by ES API internally, thus it could be removed in the future
and developer should never code against this object).
So when talking to cloud via net I will always be dealing with
TransportClinet as it can talk to many servers, contrary ServerClinet
can talk to one server only and moreover the ServerClient lives within
server scope. Does it also mean that TransportClient forwards requests
to particular ServerClients when talking to servers?