2013-08-28 19:24:34 -04:00
|
|
|
[[client]]
|
|
|
|
== Client
|
|
|
|
|
2014-05-12 22:07:46 -04:00
|
|
|
You can use the *Java client* in multiple ways:
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2015-06-24 17:27:19 -04:00
|
|
|
* Perform standard <<java-docs-index,index>>, <<java-docs-get,get>>,
|
|
|
|
<<java-docs-delete,delete>> and <<java-search,search>> operations on an
|
2013-08-28 19:24:34 -04:00
|
|
|
existing cluster
|
|
|
|
* Perform administrative tasks on a running cluster
|
|
|
|
* Start full nodes when you want to run Elasticsearch embedded in your
|
|
|
|
own application or when you want to launch unit or integration tests
|
|
|
|
|
|
|
|
Obtaining an elasticsearch `Client` is simple. The most common way to
|
|
|
|
get a client is by:
|
|
|
|
|
2014-09-02 08:59:46 -04:00
|
|
|
1. Creating an embedded <<node-client,`Node`>> that acts as a node
|
2014-05-12 22:07:46 -04:00
|
|
|
within a cluster.
|
|
|
|
2. Requesting a `Client` from your embedded `Node`.
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2014-09-02 08:59:46 -04:00
|
|
|
Another manner is by creating a <<transport-client,`TransportClient`>>
|
2013-08-28 19:24:34 -04:00
|
|
|
that connects to a cluster.
|
|
|
|
|
|
|
|
*Important:*
|
|
|
|
|
|
|
|
______________________________________________________________________________________________________________________________________________________________
|
|
|
|
Please note that you are encouraged to use the same version on client
|
2014-05-12 22:07:46 -04:00
|
|
|
and cluster sides. You may hit some incompatibility issues when mixing
|
2013-08-28 19:24:34 -04:00
|
|
|
major versions.
|
|
|
|
______________________________________________________________________________________________________________________________________________________________
|
|
|
|
|
2013-09-03 10:15:07 -04:00
|
|
|
|
2013-09-25 12:17:40 -04:00
|
|
|
[[node-client]]
|
2013-08-28 19:24:34 -04:00
|
|
|
=== Node Client
|
|
|
|
|
|
|
|
Instantiating a node based client is the simplest way to get a `Client`
|
|
|
|
that can execute operations against elasticsearch.
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
import static org.elasticsearch.node.NodeBuilder.*;
|
|
|
|
|
|
|
|
// on startup
|
|
|
|
|
|
|
|
Node node = nodeBuilder().node();
|
|
|
|
Client client = node.client();
|
|
|
|
|
|
|
|
// on shutdown
|
|
|
|
|
|
|
|
node.close();
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
When you start a `Node`, it joins an elasticsearch cluster. You can have
|
2014-05-12 22:07:46 -04:00
|
|
|
different clusters by simply setting the `cluster.name` setting, or
|
2013-08-28 19:24:34 -04:00
|
|
|
explicitly using the `clusterName` method on the builder.
|
|
|
|
|
2014-05-12 22:07:46 -04:00
|
|
|
You can define `cluster.name` in the `/src/main/resources/elasticsearch.yml`
|
2014-07-06 02:58:34 -04:00
|
|
|
file in your project. As long as `elasticsearch.yml` is present in the
|
2014-04-28 20:46:26 -04:00
|
|
|
classpath, it will be used when you start your node.
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2014-07-06 02:58:34 -04:00
|
|
|
[source,yaml]
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2014-07-06 02:58:34 -04:00
|
|
|
cluster.name: yourclustername
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Or in Java:
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
Node node = nodeBuilder().clusterName("yourclustername").node();
|
|
|
|
Client client = node.client();
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
The benefit of using the `Client` is the fact that operations are
|
|
|
|
automatically routed to the node(s) the operations need to be executed
|
|
|
|
on, without performing a "double hop". For example, the index operation
|
|
|
|
will automatically be executed on the shard that it will end up existing
|
|
|
|
at.
|
|
|
|
|
|
|
|
When you start a `Node`, the most important decision is whether it
|
|
|
|
should hold data or not. In other words, should indices and shards be
|
|
|
|
allocated to it. Many times we would like to have the clients just be
|
|
|
|
clients, without shards being allocated to them. This is simple to
|
|
|
|
configure by setting either `node.data` setting to `false` or
|
|
|
|
`node.client` to `true` (the `NodeBuilder` respective helper methods on
|
|
|
|
it):
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
import static org.elasticsearch.node.NodeBuilder.*;
|
|
|
|
|
|
|
|
// on startup
|
|
|
|
|
2015-07-30 22:46:42 -04:00
|
|
|
// Embedded node clients behave just like standalone nodes,
|
|
|
|
// which means that they will leave the HTTP port open!
|
|
|
|
Node node =
|
|
|
|
nodeBuilder()
|
|
|
|
.settings(ImmutableSettings.settingsBuilder().put("http.enabled", false))
|
|
|
|
.client(true)
|
|
|
|
.node();
|
|
|
|
|
2013-08-28 19:24:34 -04:00
|
|
|
Client client = node.client();
|
|
|
|
|
|
|
|
// on shutdown
|
|
|
|
|
|
|
|
node.close();
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Another common usage is to start the `Node` and use the `Client` in
|
|
|
|
unit/integration tests. In such a case, we would like to start a "local"
|
|
|
|
`Node` (with a "local" discovery and transport). Again, this is just a
|
|
|
|
matter of a simple setting when starting the `Node`. Note, "local" here
|
|
|
|
means local on the JVM (well, actually class loader) level, meaning that
|
|
|
|
two *local* servers started within the same JVM will discover themselves
|
|
|
|
and form a cluster.
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
import static org.elasticsearch.node.NodeBuilder.*;
|
|
|
|
|
|
|
|
// on startup
|
|
|
|
|
|
|
|
Node node = nodeBuilder().local(true).node();
|
|
|
|
Client client = node.client();
|
|
|
|
|
|
|
|
// on shutdown
|
|
|
|
|
|
|
|
node.close();
|
|
|
|
--------------------------------------------------
|
|
|
|
|
2015-07-30 22:46:42 -04:00
|
|
|
[[node-client-downsides]]
|
|
|
|
==== Node Client Downsides
|
|
|
|
|
|
|
|
Embedding a node client into your application is the easiest way to connect
|
|
|
|
to an Elasticsearch cluster, but it carries some downsides.
|
|
|
|
|
|
|
|
- Frequently starting and stopping one or more node clients creates unnecessary
|
|
|
|
noise across the cluster.
|
|
|
|
- Embedded node client will respond to outside requests, just like any other client.
|
|
|
|
** You almost always want to disable HTTP for an _embedded_ node client.
|
2013-09-03 10:15:07 -04:00
|
|
|
|
2013-09-25 12:17:40 -04:00
|
|
|
[[transport-client]]
|
2013-08-28 19:24:34 -04:00
|
|
|
=== Transport Client
|
|
|
|
|
2015-07-30 22:46:42 -04:00
|
|
|
The `TransportClient` connects remotely to an Elasticsearch cluster
|
2013-08-28 19:24:34 -04:00
|
|
|
using the transport module. It does not join the cluster, but simply
|
|
|
|
gets one or more initial transport addresses and communicates with them
|
|
|
|
in round robin fashion on each action (though most actions will probably
|
|
|
|
be "two hop" operations).
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
// on startup
|
|
|
|
|
2015-05-04 10:23:08 -04:00
|
|
|
Client client = TransportClient.builder().build()
|
2013-08-28 19:24:34 -04:00
|
|
|
.addTransportAddress(new InetSocketTransportAddress("host1", 9300))
|
|
|
|
.addTransportAddress(new InetSocketTransportAddress("host2", 9300));
|
|
|
|
|
|
|
|
// on shutdown
|
|
|
|
|
|
|
|
client.close();
|
|
|
|
--------------------------------------------------
|
|
|
|
|
2014-05-12 22:07:46 -04:00
|
|
|
Note that you have to set the cluster name if you use one different than
|
2013-08-28 19:24:34 -04:00
|
|
|
"elasticsearch":
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
2015-06-24 01:53:32 -04:00
|
|
|
Settings settings = Settings.settingsBuilder()
|
2013-08-28 19:24:34 -04:00
|
|
|
.put("cluster.name", "myClusterName").build();
|
2015-05-04 10:23:08 -04:00
|
|
|
Client client = TransportClient.builder().settings(settings).build();
|
2013-08-28 19:24:34 -04:00
|
|
|
//Add transport addresses and do something with the client...
|
|
|
|
--------------------------------------------------
|
|
|
|
|
2014-09-02 08:59:46 -04:00
|
|
|
Or using `elasticsearch.yml` file as shown in <<node-client>>
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2014-12-17 06:29:01 -05:00
|
|
|
The client allows sniffing the rest of the cluster, which adds data nodes
|
|
|
|
into its list of machines to use. In this case, note that the IP addresses
|
2013-08-28 19:24:34 -04:00
|
|
|
used will be the ones that the other nodes were started with (the
|
|
|
|
"publish" address). In order to enable it, set the
|
|
|
|
`client.transport.sniff` to `true`:
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
2015-06-24 01:53:32 -04:00
|
|
|
Settings settings = Settings.settingsBuilder()
|
2013-08-28 19:24:34 -04:00
|
|
|
.put("client.transport.sniff", true).build();
|
2015-05-04 10:23:08 -04:00
|
|
|
TransportClient client = TransportClient.builder().settings(settings).build();
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Other transport client level settings include:
|
|
|
|
|
|
|
|
[cols="<,<",options="header",]
|
|
|
|
|=======================================================================
|
|
|
|
|Parameter |Description
|
|
|
|
|`client.transport.ignore_cluster_name` |Set to `true` to ignore cluster
|
|
|
|
name validation of connected nodes. (since 0.19.4)
|
|
|
|
|
|
|
|
|`client.transport.ping_timeout` |The time to wait for a ping response
|
|
|
|
from a node. Defaults to `5s`.
|
|
|
|
|
|
|
|
|`client.transport.nodes_sampler_interval` |How often to sample / ping
|
|
|
|
the nodes listed and connected. Defaults to `5s`.
|
|
|
|
|=======================================================================
|