7.1.5 Configuring HTTP clients
Global Configuration for All Clients
The default HTTP client configuration is a Configuration Properties called DefaultHttpClientConfiguration that allows configuring the default behaviour for all HTTP clients. For example, in application.yml
:
Altering default HTTP client configuration
micronaut:
http:
client:
read-timeout: 5s
The above example sets of readTimeout
property of the HttpClientConfiguration class.
Client Specific Configuration
If you wish to have a separate configuration per client then there a couple of options. You can configure Service Discovery manually in application.yml
and apply per-client configuration:
Manually configuring HTTP services
micronaut:
http:
services:
foo:
urls:
- http://foo1
- http://foo2
read-timeout: 5s (1)
1 | The read timeout is applied to the foo client. |
WARN: This client configuration can be used in conjunction with the @Client
annotation, either by injecting an HttpClient
directly or use on a client interface. In any case, all other attributes on the annotation will be ignored other than the service id.
Then simply inject the named client configuration:
Injecting an HTTP client
@Client("foo") @Inject RxHttpClient httpClient;
You can also simply define a bean that extends from HttpClientConfiguration and ensuring that the javax.inject.Named
annotation is used to name it appropriately:
Defining an HTTP client configuration bean
@Named("twitter")
@Singleton
class TwitterHttpClientConfiguration extends HttpClientConfiguration {
public TwitterHttpClientConfiguration(ApplicationConfiguration applicationConfiguration) {
super(applicationConfiguration);
}
}
This configuration will then be picked up if you inject a service called twitter
using @Client
using Service Discovery:
Injecting an HTTP client
@Client("twitter") @Inject RxHttpClient httpClient;
Alternatively if you are not using service discovery then you can use the configuration
member of @Client
to refer to a specific type:
Injecting an HTTP client
@Client(value="https://api.twitter.com/1.1",
configuration=TwitterHttpClientConfiguration.class)
@Inject
RxHttpClient httpClient;
Using HTTP Client Connection Pooling
If you have a client that needs to handle a significant number of requests then you can benefit from enabling HTTP client connection pooling. The following configuration will enable pooling for the foo
client:
Manually configuring HTTP services
micronaut:
http:
services:
foo:
urls:
- http://foo1
- http://foo2
pool:
enabled: true (1)
max-connections: 50 (2)
1 | Enables the pool |
2 | Sets the maximum number of connections in the pool |
See the API for ConnectionPoolConfiguration for details on available options to configure the pool.
Configuring Event Loop Groups
By default Micronaut will share a common Netty EventLoopGroup
for worker threads and all HTTP clients threads.
This common EventLoopGroup
can be configured via the micronaut.netty.event-loops.default
property:
Configuring The Default Event Loop
micronaut:
netty:
event-loops:
default:
num-threads: 10
prefer-native-transport: true
You can also use the micronaut.netty.event-loops
setting to configure one or more additional event loops. The following table summarizes the properties:
Property | Type | Description |
---|---|---|
| int | |
| java.lang.Integer | |
| boolean | |
| java.lang.String |
For example, if your interactions with an HTTP client involve CPU intensive work it may be worthwhile configuring a separate EventLoopGroup
for one or all clients.
The following example configures an additional event loop group called “other” that uses 10 threads:
Configuring Additional Event Loops
micronaut:
netty:
event-loops:
other:
num-threads: 10
prefer-native-transport: true
Once an additional event loop has been configured you can alter the HTTP client configuration to use the newly defined event loop group:
Altering the Event Loop Group used by Clients
micronaut:
http:
client:
event-loop-group: other