Skip to main content


Showing posts from 2018

Brute-forcing a seemingly simple number puzzle

From StackOverflow Something was bothering me for almost two decades. It was a pen and paper game that I learned when I was around 13. The rules are simple: on an empty 10x10 grid (100 squares in total) you put a number 1 on an arbitrary square. Starting from that square you can move horizontally or vertically jumping over two squares or diagonally jumping over one square. There you can place number 2 . Your task is to reach number 100 , filling all squares. You can not visit already visited squares. Here is an example of a solved game with a reduced 5x5 grid, starting at top-left corner: 1 24 14 2 25 16 21 5 8 20 13 10 18 23 11 4 7 15 3 6 17 22 12 9 19 On the other hand, if the program makes bad choices, we might get stuck without reaching the perfect score of 25 (on a reduced 5x5 grid): 1 8 2 9 16 13 5 17 14 10 4 7 15 3 6 19 12 18 11 Notice how we got stuck at number 19, unable to move anywhere and f

Thread pool self-induced deadlocks

Summary (reading time: 10 minutes) Deadlocks are caused by many threads locking the same resources Deadlocks can also occur if thread pool is used inside a task running in that pool Modern libraries like RxJava/Reactor are also susceptible A deadlock is a situation where two or more threads are waiting for resources acquired by each other. For example thread A waits for lock1 locked by thread B, whereas thread B waits for lock2 , locked by thread A. In worst case scenario, the application freezes for an indefinite amount of time. Let me show you a concrete example. Imagine there is a Lumberjack class that holds references to two accessory locks: import; import lombok.RequiredArgsConstructor; import java.util.concurrent.locks.Lock; @RequiredArgsConstructor class Lumberjack { private final String name; private final Lock accessoryOne; private final Lock accessoryTwo; void cut(Runnable work) { try {

Sneak peek at spring-cloud-function serverless project

Almost a year ago Spring team announced spring-cloud-function umbrella project. It's basically a Spring's approach to serverless (I prefer the term function-as-a-service ) programming. Function<T, R> becomes the smallest building block in a Spring application. Functions defined as Spring beans are automatically exposed e.g. via HTTP in RPC style. Just a quick example how it looks: @SpringBootApplication public class FaasApplication { public static void main(String[] args) throws Exception {, args); } @Bean Function<Long, Person> personById(PersonRepository repo) { return repo::findById; } } @Component interface PersonRepository { Person findById(long id); Mono<Person> findByIdAsync(long id); } The implementation of PersonRepository is irrelevant here. This is a valid Spring Boot application. But once you put spring-cloud-function dependency, beans of Function t

Reactive emoji tracker with WebClient and Reactor: aggregating data

In the first part we managed to connect to and consume SSE stream that looks like this: data:{"1F60D":1} data:{"1F3A8":1,"1F48B":1,"1F499":1,"1F602":1,"2764":1} data:{"1F607":1,"2764":2} Each message represents the number of various emojis that appeared on Twitter since the previous message. After a few transformations, we got a stream of hexadecimal Unicode values for each emoji. E.g. for {"1F607":1,"2764":2} we produce three events: "1F607" , "2764" , "2764" . This is how we achieved it: import org.springframework.http.codec.ServerSentEvent; import org.springframework.web.reactive.function.client.WebClient; import reactor.core.publisher.Flux; import reactor.core.publisher.Mono; final Flux<String> stream = WebClient .create("") .get().uri("/subscribe/e

Reactive emoji tracker with WebClient and Reactor: consuming SSE

In this article we will learn how to consume infinite SSE (server-sent events) stream with Spring's WebClient and Project Reactor . WebClient is a new HTTP client in Spring 5, entirely asynchronous and natively supporting Flux and Mono types. You can technically open thousands of concurrent HTTP connections with just a handful of threads. In standard RestTemplate one HTTP connection always needs at least one thread. As an example, let's connect to this cute little site called . It shows emojis being used in real-time on Twitter. Looks quite cool! All credits go to Matthew Rothenberg , the creator of that site. It's very dynamic so there obviously has to be some push mechanism underneath. I wore my hacker glasses and after hours of penetration testing, I discovered the following URL in Chrome DevTools: . If you connect to it, you'll get a fast stream of emoji counters: $ curl -v http://em

Spring Boot 2: Fluxes, from Elasticsearch to controller

Bieszczady Mountains The final piece of the puzzle in our series is exposing reactive APIs via RESTful interfaces. Previously we were seeding our Elasticsearch with some sample fake data . Now it's about time to expose indexing functionality through some API. Let's start with some simple adapter to our indexing engine: import lombok.RequiredArgsConstructor; import org.elasticsearch.action.ActionListener; import org.elasticsearch.action.index.IndexRequest; import org.elasticsearch.action.index.IndexResponse; import org.elasticsearch.client.RestHighLevelClient; import org.elasticsearch.common.xcontent.XContentType; import org.springframework.stereotype.Component; import reactor.core.publisher.Mono; import reactor.core.publisher.MonoSink; @Component @RequiredArgsConstructor class ElasticAdapter { private final RestHighLevelClient client; private final ObjectMapper objectMapper; Mono<IndexResponse> index(Person doc) { return indexDoc(doc); }

Spring Boot 2: Migrating from Dropwizard metrics to Micrometer

Spring Boot 2 is around the corner. One of the minor changes is the replacement of Dropwizard Metrics with Micrometer . The migration path is fairly straightforward and Micrometer actually provides cleaner API. With Metrics, you have to inject MetricRegistry wherever you need some metrics (see: Monitoring and measuring reactive application with Dropwizard Metrics ). This has many drawbacks: we are mixing business and technical dependencies in our components therefore I am sometimes reluctant to add new metrics because it requires me to inject MetricRegistry also MetricRegistry must be stubbed in unit tests Micrometer's tagline is: Think SLF4J, but for metrics It's actually quite accurate. Whenever I need a Logger I don't inject LoggerFactory , instead I simply use static methods available everywhere. The same goes for Micrometer, I simply use static factory methods on globally available Metrics class: private final Timer indexTimer = Metrics.timer("e

Monitoring and measuring reactive application with Dropwizard Metrics

In the previous article we created a simple indexing code that hammers ElasticSearch with thousands of concurrent requests. The only way to monitor the performance of our system was an old-school logging statement: .window(Duration.ofSeconds(1)) .flatMap(Flux::count) .subscribe(winSize -> log.debug("Got {} responses in last second", winSize)); It's fine, but on a production system, we'd rather have some centralized monitoring and charting solution for gathering various metrics. This becomes especially important once you have hundreds of different applications in thousands of instances. Having a single graphical dashboard, aggregating all important information, becomes crucial. We need two components in order to collect some metrics: publishing metrics collecting and visualizing them Publishing metrics using Dropwizard Metrics In Spring Boot 2 Dropwizard Metrics were replaced by Micrometer . This article uses the former, the next one will show the latte