2017-07-04 04:58:57 -04:00
== Common configuration
2016-07-29 05:22:47 -04:00
2017-07-06 04:05:50 -04:00
As explained in <<java-rest-low-usage-initialization>>, the `RestClientBuilder`
supports providing both a `RequestConfigCallback` and an `HttpClientConfigCallback`
which allow for any customization that the Apache Async Http Client exposes.
Those callbacks make it possible to modify some specific behaviour of the client
without overriding every other default configuration that the `RestClient`
is initialized with. This section describes some common scenarios that require
additional configuration for the low-level Java REST Client.
2016-07-29 05:22:47 -04:00
2017-07-04 04:58:57 -04:00
=== Timeouts
2016-07-29 05:22:47 -04:00
Configuring requests timeouts can be done by providing an instance of
`RequestConfigCallback` while building the `RestClient` through its builder.
2017-08-29 10:26:36 -04:00
The interface has one method that receives an instance of
https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/config/RequestConfig.Builder.html[`org.apache.http.client.config.RequestConfig.Builder`]
2016-07-29 05:22:47 -04:00
as an argument and has the same return type. The request config builder can
be modified and then returned. In the following example we increase the
2016-12-05 10:54:51 -05:00
connect timeout (defaults to 1 second) and the socket timeout (defaults to 30
seconds). Also we adjust the max retry timeout accordingly (defaults to 30
2016-07-29 05:22:47 -04:00
seconds too).
2017-07-06 04:05:50 -04:00
["source","java",subs="attributes,callouts,macros"]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
include-tagged::{doc-tests}/RestClientDocumentation.java[rest-client-config-timeouts]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-04 04:58:57 -04:00
=== Number of threads
2016-07-29 05:22:47 -04:00
The Apache Http Async Client starts by default one dispatcher thread, and a
number of worker threads used by the connection manager, as many as the number
of locally detected processors (depending on what
`Runtime.getRuntime().availableProcessors()` returns). The number of threads
can be modified as follows:
2017-07-06 04:05:50 -04:00
["source","java",subs="attributes,callouts,macros"]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
include-tagged::{doc-tests}/RestClientDocumentation.java[rest-client-config-threads]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-04 04:58:57 -04:00
=== Basic authentication
2016-07-29 05:22:47 -04:00
Configuring basic authentication can be done by providing an
`HttpClientConfigCallback` while building the `RestClient` through its builder.
2017-08-29 10:26:36 -04:00
The interface has one method that receives an instance of
https://hc.apache.org/httpcomponents-asyncclient-dev/httpasyncclient/apidocs/org/apache/http/impl/nio/client/HttpAsyncClientBuilder.html[`org.apache.http.impl.nio.client.HttpAsyncClientBuilder`]
2016-07-29 05:22:47 -04:00
as an argument and has the same return type. The http client builder can be
modified and then returned. In the following example we set a default
credentials provider that requires basic authentication.
2017-07-06 04:05:50 -04:00
["source","java",subs="attributes,callouts,macros"]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
include-tagged::{doc-tests}/RestClientDocumentation.java[rest-client-config-basic-auth]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
Preemptive Authentication can be disabled, which means that every request will be sent without
2017-01-24 11:34:05 -05:00
authorization headers to see if it is accepted and, upon receiving a HTTP 401 response, it will
resend the exact same request with the basic authentication header. If you wish to do this, then
you can do so by disabling it via the `HttpAsyncClientBuilder`:
2017-07-06 04:05:50 -04:00
["source","java",subs="attributes,callouts,macros"]
2017-01-24 11:34:05 -05:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
include-tagged::{doc-tests}/RestClientDocumentation.java[rest-client-config-disable-preemptive-auth]
2017-01-24 11:34:05 -05:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
<1> Disable preemptive authentication
2017-01-24 11:34:05 -05:00
2017-07-04 04:58:57 -04:00
=== Encrypted communication
2016-07-29 05:22:47 -04:00
Encrypted communication can also be configured through the
2017-08-29 10:26:36 -04:00
`HttpClientConfigCallback`. The
https://hc.apache.org/httpcomponents-asyncclient-dev/httpasyncclient/apidocs/org/apache/http/impl/nio/client/HttpAsyncClientBuilder.html[`org.apache.http.impl.nio.client.HttpAsyncClientBuilder`]
2016-07-29 05:22:47 -04:00
received as an argument exposes multiple methods to configure encrypted
communication: `setSSLContext`, `setSSLSessionStrategy` and
`setConnectionManager`, in order of precedence from the least important.
The following is an example:
2017-07-06 04:05:50 -04:00
["source","java",subs="attributes,callouts,macros"]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-06 04:05:50 -04:00
include-tagged::{doc-tests}/RestClientDocumentation.java[rest-client-config-encrypted-communication]
2016-07-29 05:22:47 -04:00
--------------------------------------------------
2017-07-20 09:36:56 -04:00
If no explicit configuration is provided, the http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores[system default configuration]
will be used.
2017-07-04 04:58:57 -04:00
=== Others
2016-07-29 05:22:47 -04:00
For any other required configuration needed, the Apache HttpAsyncClient docs
2016-12-05 10:54:51 -05:00
should be consulted: https://hc.apache.org/httpcomponents-asyncclient-4.1.x/ .
2018-03-22 21:23:52 -04:00
NOTE: If your application runs under the security manager you might be subject
to the JVM default policies of caching positive hostname resolutions
indefinitely and negative hostname resolutions for ten seconds. If the resolved
addresses of the hosts to which you are connecting the client to vary with time
then you might want to modify the default JVM behavior. These can be modified by
adding
http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html[`networkaddress.cache.ttl=<timeout>`]
and
http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html[`networkaddress.cache.negative.ttl=<timeout>`]
to your
http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html[Java
security policy].
2018-06-22 11:15:29 -04:00
=== Node selector
The client sends each request to one of the configured nodes in round-robin
fashion. Nodes can optionally be filtered through a node selector that needs
to be provided when initializing the client. This is useful when sniffing is
enabled, in case only dedicated master nodes should be hit by HTTP requests.
For each request the client will run the eventually configured node selector
to filter the node candidates, then select the next one in the list out of the
remaining ones.
["source","java",subs="attributes,callouts,macros"]
--------------------------------------------------
include-tagged::{doc-tests}/RestClientDocumentation.java[rest-client-init-allocation-aware-selector]
--------------------------------------------------
<1> Set an allocation aware node selector that allows to pick a node in the
local rack if any available, otherwise go to any other node in any rack. It
acts as a preference rather than a strict requirement, given that it goes to
another rack if none of the local nodes are available, rather than returning
no nodes in such case which would make the client forcibly revive a local node
whenever none of the nodes from the preferred rack is available.
WARNING: Node selectors that do not consistently select the same set of nodes
will make round-robin behaviour unpredictable and possibly unfair. The
preference example above is fine as it reasons about availability of nodes
which already affects the predictability of round-robin. Node selection should
not depend on other external factors or round-robin will not work properly.