Riptide: Timeout

Client side response routing

License

License

Categories

Categories

IDE Development Tools Riptide Net HTTP Clients
GroupId

GroupId

org.zalando
ArtifactId

ArtifactId

riptide-timeout
Last Version

Last Version

3.0.0-RC.4
Release Date

Release Date

Type

Type

jar
Description

Description

Riptide: Timeout
Client side response routing
Project Organization

Project Organization

Zalando SE

Download riptide-timeout

How to add to project

<!-- https://jarcasting.com/artifacts/org.zalando/riptide-timeout/ -->
<dependency>
    <groupId>org.zalando</groupId>
    <artifactId>riptide-timeout</artifactId>
    <version>3.0.0-RC.4</version>
</dependency>
// https://jarcasting.com/artifacts/org.zalando/riptide-timeout/
implementation 'org.zalando:riptide-timeout:3.0.0-RC.4'
// https://jarcasting.com/artifacts/org.zalando/riptide-timeout/
implementation ("org.zalando:riptide-timeout:3.0.0-RC.4")
'org.zalando:riptide-timeout:jar:3.0.0-RC.4'
<dependency org="org.zalando" name="riptide-timeout" rev="3.0.0-RC.4">
  <artifact name="riptide-timeout" type="jar" />
</dependency>
@Grapes(
@Grab(group='org.zalando', module='riptide-timeout', version='3.0.0-RC.4')
)
libraryDependencies += "org.zalando" % "riptide-timeout" % "3.0.0-RC.4"
[org.zalando/riptide-timeout "3.0.0-RC.4"]

Dependencies

compile (6)

Group / Artifact Type Version
org.zalando : riptide-core jar 3.0.0-RC.4
org.apiguardian : apiguardian-api jar 1.1.0
org.zalando : faux-pas jar 0.8.0
com.google.code.findbugs : jsr305 jar 3.0.2
com.google.guava : guava jar 28.0-jre
org.slf4j : slf4j-api jar 1.7.28

provided (2)

Group / Artifact Type Version
com.google.gag : gag jar 1.0.1
org.projectlombok : lombok jar 1.18.8

test (17)

Group / Artifact Type Version
org.springframework : spring-test jar 5.1.9.RELEASE
com.github.rest-driver : rest-client-driver jar 2.0.0
org.zalando : riptide-httpclient jar 3.0.0-RC.4
org.slf4j : jcl-over-slf4j jar 1.7.28
org.slf4j : slf4j-simple jar 1.7.28
org.junit.jupiter : junit-jupiter-api jar 5.5.1
org.junit.jupiter : junit-jupiter-engine jar 5.5.1
org.junit.jupiter : junit-jupiter-params jar 5.5.1
org.hamcrest : java-hamcrest jar 2.0.0.0
org.hobsoft.hamcrest : hamcrest-compose jar 0.4.0
org.mockito : mockito-core jar 3.0.0
org.mockito : mockito-junit-jupiter jar 3.0.0
com.fasterxml.jackson.core : jackson-core jar 2.10.0.pr1
com.fasterxml.jackson.core : jackson-databind jar 2.10.0.pr1
com.fasterxml.jackson.module : jackson-module-parameter-names jar 2.10.0.pr1
com.fasterxml.jackson.datatype : jackson-datatype-jdk8 jar 2.10.0.pr1
org.zalando : jackson-datatype-problem jar 0.23.0

Project Modules

There are no modules declared in this project.

Riptide: A next generation HTTP client

Tidal wave

Stability: Active Build Status Coverage Status Code Quality Javadoc Release Maven Central License

Riptide noun, /ˈrɪp.taɪd/: strong flow of water away from the shore

Riptide is a library that implements client-side response routing. It tries to fill the gap between the HTTP protocol and Java. Riptide allows users to leverage the power of HTTP with its unique API.

  • Technology stack: Based on spring-web and uses the same foundation as Spring's RestTemplate.
  • Status: Actively maintained and used in production.
  • Riptide is unique in the way that it doesn't abstract HTTP away, but rather embrace it!

🚨 Upgrading from 2.x to 3.x? Please refer to the Migration Guide.

Example

Usage typically looks like this:

http.get("/repos/{org}/{repo}/contributors", "zalando", "riptide")
    .dispatch(series(),
        on(SUCCESSFUL).call(listOf(User.class), users -> 
            users.forEach(System.out::println)));

Feel free to compare this e.g. to Feign or Retrofit.

Features

Origin

Most modern clients try to adapt HTTP to a single-return paradigm as shown in the following example. Even though this may be perfectly suitable for most applications it takes away a lot of the power that comes with HTTP. It's not easy to support multiple different return values, i.e. distinct happy cases. Access to response headers or manual content negotiation are also harder to do.

@GET
@Path("/repos/{org}/{repo}/contributors")
List<User> getContributors(@PathParam String org, @PathParam String repo);

Riptide tries to counter this by providing a different approach to leverage the power of HTTP. Go checkout the concept document for more details.

Dependencies

  • Spring 4.1 or higher
    • ⚠️ Spring Boot integration requires Spring 5

Installation

Add the following dependency to your project:

<dependency>
    <groupId>org.zalando</groupId>
    <artifactId>riptide-core</artifactId>
    <version>${riptide.version}</version>
</dependency>

Additional modules/artifacts of Riptide always share the same version number.

Alternatively, you can import our bill of materials...

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.zalando</groupId>
      <artifactId>riptide-bom</artifactId>
      <version>${riptide.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

... which allows you to omit versions:

<dependencies>
  <dependency>
      <groupId>org.zalando</groupId>
      <artifactId>riptide-core</artifactId>
  </dependency>
  <dependency>
      <groupId>org.zalando</groupId>
      <artifactId>riptide-failsafe</artifactId>
  </dependency>
  <dependency>
      <groupId>org.zalando</groupId>
      <artifactId>riptide-faults</artifactId>
  </dependency>
</dependencies>

Configuration

Integration of your typical Spring Boot Application with Riptide, Logbook and Tracer can be greatly simplified by using the Riptide: Spring Boot Starter. Go check it out!

Http.builder()
    .executor(Executors.newCachedThreadPool())
    .requestFactory(new HttpComponentsClientHttpRequestFactory())
    .baseUrl("https://api.github.com")
    .converter(new MappingJackson2HttpMessageConverter())
    .converter(new Jaxb2RootElementHttpMessageConverter())
    .plugin(new OriginalStackTracePlugin())
    .build();

The following code is the bare minimum, since a request factory is required:

Http.builder()
    .executor(Executors.newCachedThreadPool())
    .requestFactory(new HttpComponentsClientHttpRequestFactory())
    .build();

This defaults to:

Thread Pool

All off the standard Executors.new*Pool() implementations only support the queue-first style, i.e. the pool scales up to the core pool size, then fills the queue and only then will scale up to the maximum pool size.

Riptide provides a ThreadPoolExecutors.builder() which also offers a scale-first style where thread pools scale up to the maximum pool size before they queue any tasks. That usually leads to higher throughput, lower latency on the expense of having to maintain more threads.

The following table shows which combination of properties are supported

Configuration Supported
Without queue, fixed size¹ ✔️
Without queue, elastic size² ✔️
Bounded queue, fixed size ✔️
Bounded queue, elastic size ✔️
Unbounded queue, fixed size ✔️
Unbounded queue, elastic size ³
Scale first, without queue, fixed size
Scale first, without queue, elastic size
Scale first, bounded queue, fixed size
Scale first, bounded queue, elastic size ✔️
Scale first, unbounded queue, fixed size
Scale first, unbounded queue, elastic size ✔️

¹ Core pool size = maximum pool size
² Core pool size < maximum pool size
³ Pool can't grow past core pool size due to unbounded queue
⁴ Scale first has no meaning without a queue
⁵ Fixed size pools are already scaled up
⁶ Elastic, but only between 0 and maximum pool size

Examples

  1. Without queue, elastic size

    ThreadPoolExecutors.builder()
        .withoutQueue()
        .elasticSize(5, 20)
        .keepAlive(1, MINUTES)
        .build(ze
  2. Bounded queue, fixed size

    ThreadPoolExecutors.builder()
        .boundedQueue(20)
        .fixedSize(20)
        .keepAlive(1, MINUTES)
        .build()
  3. Scale-first, unbounded queue, elastic size

    ThreadPoolExecutors.builder()
        .scaleFirst()
        .unboundedQueue()
        .elasticSize(20)   
        .keepAlive(1, MINUTES)
        .build()

You can read more about scale-first here:

In order to configure the thread pool correctly, please refer to How to set an ideal thread pool size.

Non-blocking IO

Riptide supports two different kinds of request factories:

ClientHttpRequestFactory

The following implementations offer blocking IO:

AsyncClientHttpRequestFactory

The following implementations offer non-blocking IO:

Non-blocking IO is asynchronous by nature. In order to provide asynchrony for blocking IO you need to register an executor. Not passing an executor will make all network communication synchronous, i.e. all futures returned by Riptide will already be completed.

Synchronous Asynchronous
Blocking IO ClientHttpRequestFactory Executor + ClientHttpRequestFactory
Non-blocking IO n/a AsyncClientHttpRequestFactory

Usage

Requests

A full-blown request may contain any of the following aspects: HTTP method, request URI, query parameters, headers and a body:

http.post("/sales-order")
    .queryParam("async", "false")
    .contentType(CART)
    .accept(SALES_ORDER)
    .header("Client-IP", "127.0.0.1")
    .body(cart)
    //...

Riptide supports the following HTTP methods: get, head, post, put, patch, delete, options and trace respectively. Query parameters can either be provided individually using queryParam(String, String) or multiple at once with queryParams(Multimap<String, String>).

The following operations are applied to URI Templates (get(String, Object...)) and URIs (get(URI)) respectively:

URI Template

URI

  • none, used as is
  • expected to be already encoded

Both

  • after respective transformation
  • resolved against Base URL (if present)
  • Query String (merged with existing)
  • Normalization

The URI Resolution table shows some examples how URIs are resolved against Base URLs, based on the chosen resolution strategy.

The Content-Type- and Accept-header have type-safe methods in addition to the generic support that is header(String, String) and headers(HttpHeaders).

Responses

Riptide is special in the way it handles responses. Rather than having a single return value, you need to register callbacks. Traditionally you would attach different callbacks for different response status codes, alternatively there are also built-in routing capabilities on status code families (called series in Spring) as well as on content types.

http.post("/sales-order")
    // ...
    .dispatch(series(),
        on(SUCCESSFUL).dispatch(contentType(),
            on(SALES_ORDER).call(SalesOrder.class, this::persist),
        on(CLIENT_ERROR).dispatch(status(),
            on(CONFLICT).call(this::retry),
            on(PRECONDITION_FAILED).call(this::readAgainAndRetry),
            anyStatus().call(problemHandling())),
        on(SERVER_ERROR).dispatch(status(),
            on(SERVICE_UNAVAILABLE).call(this::scheduleRetryLater))));

The callbacks can have the following signatures:

persist(SalesOrder)
retry(ClientHttpResponse)
scheduleRetryLater()

Futures

Riptide will return a CompletableFuture<ClientHttpResponse>. That means you can choose to chain transformations/callbacks or block on it.

If you need proper return values take a look at Riptide: Capture.

Exceptions

The only special custom exception you may get is UnexpectedResponseException, if and only if there was no matching condition and no wildcard condition either.

Plugins

Riptide comes with a way to register extensions in the form of plugins.

  • OriginalStackTracePlugin, preserves stack traces when executing requests asynchronously
  • AuthorizationPlugin, adds Authorization support
  • FailsafePlugin, adds retries, circuit breaker, backup requests and timeout support
  • MicrometerPlugin, adds metrics for request duration
  • TransientFaults, detects transient faults, e.g. network issues Whenever you encounter the need to perform some repetitive task on the futures returned by a remote call, you may consider implementing a custom Plugin for it.

Plugins are executed in phases:

Plugin phases

Please consult the Plugin documentation for details.

Testing

Riptide is built on the same foundation as Spring's RestTemplate and AsyncRestTemplate. That allows us, with a small trick, to use the same testing facilities, the MockRestServiceServer:

RestTemplate template = new RestTemplate();
MockRestServiceServer server = MockRestServiceServer.createServer(template);
ClientHttpRequestFactory requestFactory = template.getRequestFactory();

Http.builder()
    .requestFactory(requestFactory)
    // continue configuration

We basically use an intermediate RestTemplate as a holder of the special ClientHttpRequestFactory that the MockRestServiceServer manages.

If you are using the Spring Boot Starter the test setup is provided by a convenient annotation @RiptideClientTest, see here.

Getting help

If you have questions, concerns, bug reports, etc., please file an issue in this repository's Issue Tracker.

Getting involved/Contributing

To contribute, simply make a pull request and add a brief description (1-2 sentences) of your addition or change. For more details check the contribution guidelines.

Credits and references

org.zalando

Zalando SE

The org page for Zalando, Europe's leading online fashion platform. Visit opensource.zalando.com for project stats.

Versions

Version
3.0.0-RC.4
3.0.0-RC.3
3.0.0-RC.2
3.0.0-RC.1
3.0.0-RC.0
2.11.0
2.10.1
2.10.0
2.9.0
2.9.0-RC.4
2.9.0-RC.3
2.9.0-RC.2
2.9.0-RC.1
2.9.0-RC.0
2.8.1
2.8.0
2.7.1
2.7.0
2.6.1
2.6.0
2.6.0-RC8
2.6.0-RC7
2.6.0-RC6
2.6.0-RC5
2.6.0-RC4
2.6.0-RC3
2.6.0-RC2
2.6.0-RC1
2.6.0-beta