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

  1. micronaut:
  2. http:
  3. client:
  4. 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

  1. micronaut:
  2. http:
  3. services:
  4. foo:
  5. urls:
  6. - http://foo1
  7. - http://foo2
  8. read-timeout: 5s (1)
1The 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

  1. @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

  1. @Named("twitter")
  2. @Singleton
  3. class TwitterHttpClientConfiguration extends HttpClientConfiguration {
  4. public TwitterHttpClientConfiguration(ApplicationConfiguration applicationConfiguration) {
  5. super(applicationConfiguration);
  6. }
  7. }

This configuration will then be picked up if you inject a service called twitter using @Client using Service Discovery:

Injecting an HTTP client

  1. @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

  1. @Client(value="https://api.twitter.com/1.1",
  2. configuration=TwitterHttpClientConfiguration.class)
  3. @Inject
  4. 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

  1. micronaut:
  2. http:
  3. services:
  4. foo:
  5. urls:
  6. - http://foo1
  7. - http://foo2
  8. pool:
  9. enabled: true (1)
  10. max-connections: 50 (2)
1Enables the pool
2Sets 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

  1. micronaut:
  2. netty:
  3. event-loops:
  4. default:
  5. num-threads: 10
  6. 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:

🔗

Table 1. Configuration Properties for DefaultEventLoopGroupConfiguration
PropertyTypeDescription

micronaut.netty.event-loops..num-threads

int

micronaut.netty.event-loops..io-ratio

java.lang.Integer

micronaut.netty.event-loops..prefer-native-transport

boolean

micronaut.netty.event-loops..executor

java.lang.String

micronaut.netty.event-loops..shutdown-quiet-period

java.time.Duration

micronaut.netty.event-loops..shutdown-timeout

java.time.Duration

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

  1. micronaut:
  2. netty:
  3. event-loops:
  4. other:
  5. num-threads: 10
  6. 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

  1. micronaut:
  2. http:
  3. client:
  4. event-loop-group: other