Forem: Igor Perikov

Why I like Go HTTP client as a Java developer

Igor Perikov — Tue, 26 Nov 2019 10:18:39 +0000

We live in era of microservices. Those have A LOT of communication happening inside their ecosystems. You might have seen so-called death stars of microservices:

image by Cornell University researchers

Every single click in modern internet triggers multitudes of network calls and, as you probably know, network is unreliable. This is one of the reasons you should set request timeouts when fetching something over the wire. It's better to incorporate some other techniques as well, but that's the topic for another article (and even whole book).

Why bother about timeouts?

Setting them is very important, because network might fail, your instance might get slow or crash. You don't want users to wait indefinitely just because 1 of your 1000 servers suddenly shut down. People hate waiting, it affects their happiness and, therefore, your revenue. If network call gets stuck, you should abandon it, retry and, unless your cluster is having problems, it most likely to succeed.

Let's see how we can implement this in Java and Go.

Common Java approach

Most popular http client in java is Apache HttpClient. Here's how configuring request timeouts will look like:

RequestConfig config = RequestConfig.custom()
    .setConnectTimeout(100)
    .setConnectionRequestTimeout(100)
    .setSocketTimeout(300)
    .build();

Those 3 are all different and independent. Biggest problem we're facing here is how to represent 500 ms as 3 different timeouts, should it be 100 + 100 + 300 or 50 + 50 + 400? And, more importantly, do we even care if connect timeout will take 200 ms? Imagine that server will complete request in 50 ms, so total response time would be 250 ms, in most situations you don't care, it's completely fine!

On the other side you can't set timeouts much bigger, because it will lead to a longer requests. Also, socket timeout is just a timeout between any consecutive packets being read from the socket, not the whole response being sent back to you.

Nonetheless, it's all we can do using Apache HttpClient. Let's take a look at Go.

Go standard library

Go, however, has support for whole client call timeout:

callTimeoutMs := 2000
httpClient := http.Client{Timeout: time.Duration(callTimeoutMs) * time.Millisecond}
_, err := httpClient.Get("http://httpbin.org/delay/1") // this waits 1 second
if err != nil {
    log.Fatal(err)
}

Here we're setting call timeout to 2 seconds and calling httpbin, which will imitate work for 1 second long and return a response after. Launching this will lead to a successful call.

If we set call timeout to 1 second it will fail with a message similar to given , which is exactly what we are looking for!

2019/11/25 19:06:09 Get http://httpbin.org/delay/1: net/http:
 request canceled (Client.Timeout exceeded while awaiting headers)

On the contrary, configuring call timeout only is not always the best we can achieve. Imagine having a long and heavy request which takes 10 seconds to complete. It would be nasty to wait 10 seconds for response and figure out that servers was trying to establish connection all this time and no actual work was done.

Solution to this? Connect timeout. Yes, the one we were sort of blaming earlier. Combined with call timeout it gives robust protection to your network interactions:

callTimeoutMs := 10000
connectTimeoutMs := 25
httpClient := http.Client{
    Timeout: time.Duration(callTimeoutMs) * time.Millisecond,
    Transport: &http.Transport{
        DialContext: (&net.Dialer{
            Timeout: time.Duration(connectTimeoutMs) * time.Millisecond,
        }).DialContext,
    },
}
_, err := httpClient.Get("http://httpbin.org/delay/5") // this waits for 5 seconds
if err != nil {
    log.Fatal(err)
}

Exceeding connect timeout will give us desirable behavior:
2019/11/25 19:12:25 Get http://httpbin.org/delay/5: dial tcp 54.172.95.6:80: i/o timeout
Go gives you a lot of flexibility with it's standard HTTP client, and library is supported by the vendor - perfect combination, that's why I like it very much! Now let's get back to Java world one more time.

So, is Java doomed?

No. There are less popular alternatives, such as JDK 11 http client and OkHttp, which supports call timeout features. Sadly, those are not the top results when searching on Google, so people are less aware of them or not willing to start using them.

JDK 11

It is a modern http client delivered with standard library, which supports HTTP/1.1, HTTP/2, async calls via CompletableFuture and provides convenient api to work with. Let's combine both timeouts with it:

HttpClient httpClient = HttpClient.newBuilder()
    .connectTimeout(Duration.ofMillis(50))
    .version(HttpClient.Version.HTTP_1_1)
    .build();
HttpRequest request = HttpRequest.newBuilder()
    .GET()
    .uri(URI.create("http://httpbin.org/delay/1"))
    .timeout(Duration.ofMillis(2000))
    .build();
httpClient.send(request, HttpResponse.BodyHandlers.ofString());

This client will provide nice and easy to understand error messages(especially compared to Go) for connect and call timeouts respectively:

Exception in thread "main" java.net.http.HttpConnectTimeoutException: 
 HTTP connect timed out

Exception in thread "main" java.net.http.HttpTimeoutException:
 request timed out

OkHttp

OkHttp supports call and connect timeouts too. Both can be configured at client abstraction level, which is slightly more convenient compared to JDK11 implementation:

OkHttpClient httpClient = new OkHttpClient.Builder()
    .connectTimeout(Duration.ofMillis(100))
    .callTimeout(Duration.ofMillis(1000))
    .build();

How to choose timeout values, anyway?

Last thing I'd like to mention is how to derive those 2 numbers. Call timeout is more about SLA/SLO you have with other services and connect timeout is about expectations from underlying network. For example, if you're sending requests to the same datacenter, then 100ms would be fine (although it should establish connection faster than 5ms), but operating on top of mobile networks (which are more error-prone) will require higher connect timeouts.

Wrap-up

In this article we discussed why timeouts are important, why 'classic' timeouts doesn't meet modern requirements and which instruments to use to force them. I hope you found something useful in it.

Mighty-watcher digest #1

Igor Perikov — Fri, 04 Oct 2019 16:40:50 +0000

Introductory post on what mighty-watcher is

First of all, thanks to everyone who have supported me in any way ❤️ I don't know how many of you have tried mighty-watcher so far, but if u did, I hope you enjoyed it. I feel motivated to keep writing articles, especially about things, other than mighty-watcher. TBH, I've already started writing a new one! It will be more technical with a bit of comparison between java and go.

Development news

There are currently 2 things which are in-progress:

Right now I am working on supporting advanced mode. It's a mode for those who are looking for harder issues, have broad experience and probably have contributed to repository already.
My brother is implementing support for html reports. It was his idea on how to make output more convenient and user-friendly. You can track his progress here. Here is example:

Hacktoberfest

If you haven't finished your hacktoberfest goals yet or just want to make a contribution to kotlin-based project - I have some issues available. Or use it to find issues in your favorite(and starred ⭐) open-source projects. As usual if you have something in mind - don't hesitate to discuss it.

Open source made easier

Igor Perikov — Tue, 01 Oct 2019 06:44:51 +0000

TL;DR

I made a program that finds, among your starred repositories, the issues that are most likely to be a good choice for making a contribution. For a quick start, check out the How-To on the GitHub project page.

Why would one need it?

Developers are obsessed with open source development nowadays. Everyone wants to give back to the community, to get some new skills and experience while working on the most widely known software products. Imagine getting invaluable insights from experienced engineers all over the world: pretty exciting, right?

However, people struggle hard to find appropriate tasks to work on. If you are new to the project, it is most likely that the maintainers won’t let you work on some big, fancy feature, lest you miss a plenty of details and corner cases. Everyone agrees that one would better start with the easiest tasks, learn the ropes, get some trust from maintainers, and then proceed to harder ones.

So, how do you find these easy issues to work on?

Some time ago, GitHub started listing appropriate issues, e.g., https://github.com/golang/go/contribute. You can access this list from the header of the Issues page. This is how it looks like:

Although it is pretty accurate, it sometimes lacks the appropriate labeling or misses some items.

My usual "let-me-make-a-contribution" day used to look like this: I was looking through my starred repositories and jumping to this “new contribution” section, or was scrolling the issues list manually. That was a very monotonous and time-consuming task, so I used to get bored quickly by this process and would give up. That is when I decided to automate it.

Solution

First, I needed to work out the rules of the game. I did some research and came up with the following heuristics:

An issue should not be closed.
Assigned means assigned, don’t waste your time on it.
An issue should be marked with an “easy” label or something similar.
Old issues are likely to be outdated; if it remains unsolved for too long, maintainers are likely not interested in it and probably less interested to help you during the process.

Furthermore, it turns out that every repository uses its own set of labels, and it is rarely just “help wanted”. There are multitudes of them. I looked through all the labels in my starred repositories and other popular ones and came up with a final list of ~60 labels. If any of your repositories have different labels, create a pull request or contact me — I will add it as soon as possible. As I set boundaries, it was the time to create the program itself.

I built a Kotlin application, which looks through the list of starred repositories and searches for the issues with predefined labels, sorts them and has them printed to the console. The current way of distribution is a Docker image — people are more likely to have it installed than Java ;)

As the labels list grew, I noticed a drastic decrease in speed and an increase in the consumption of API usage limits. The first edition of the tool was searching for issues with all given labels, although 95% of them had never been used in that repo! That was my “AHA!” moment, so I added an additional call to fetch all the labels from the repository and intersect them with my list. I got a significant improvement of the performance, and utilized less of the API limits.

On a daily basis, the tool works fine as a guide to the world of open-source contributions, it will also help you to achieve your Hacktoberfest goals. To try it, go to the project page and follow the instructions. If you lack starred repositories - I have some advices for you as well.

If you have something to say — do it in the section below, or in the dedicated feedback issue.