7.1.5 Configuring HTTP clients

Global Configuration for All Clients

The default HTTP client configuration is a Configuration Properties named 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 the readTimeout property of the HttpClientConfiguration class.

Client Specific Configuration

To have separate configuration per-client, there are 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)

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 except the service id.

Then, inject the named client configuration:

Injecting an HTTP client

@Client("foo") @Inject ReactorHttpClient httpClient;

You can also define a bean that extends from HttpClientConfiguration and ensure that the javax.inject.Named annotation names it appropriately:

Defining an HTTP client configuration bean

@Named("twitter")
@Singleton
class TwitterHttpClientConfiguration extends HttpClientConfiguration {
   public TwitterHttpClientConfiguration(ApplicationConfiguration configuration) {
        super(configuration);
    }
}

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

Injecting an HTTP client

@Client("twitter") @Inject ReactorHttpClient httpClient;

Alternatively, if you don’t use service discovery 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
ReactorHttpClient httpClient;

Using HTTP Client Connection Pooling

A client that handles a significant number of requests will benefit from enabling HTTP client connection pooling. The following configuration enables 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)

See the API for ConnectionPoolConfiguration for details on available pool configuration options.

Configuring Event Loop Groups

By default, Micronaut shares a common Netty EventLoopGroup for worker threads and all HTTP client threads.

This 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:

🔗

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” with 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 it:

Altering the Event Loop Group used by Clients

micronaut:
  http:
    client:
      event-loop-group: other