Posted on

Why the Cool Kids Use Event Loops

When I was working in software development back in the 1990s, nearly all the software libraries that I worked on made use of event loops. This was because at the time most hardware had just one single CPU. Back in the day, I remember the excitement when threads were introduced into our development framework. It was revolutionary that we could now run two things at once, or rather appear to run two things at once, since a lot of the hardware at that time still only had a single core, and hence our threaded code was never really truly concurrent.

Over the years I've had mixed feelings about threads. Some of the most challenging systems that I’ve maintained have suffered from the overuse or misunderstood impact of concurrency. Even today I have discussions around if a piece of code is truly thread-safe and although the libraries (for example, the Java Concurrency Library) have made massive improvements reducing the burden of developing with threads, it is still somewhat of a challenge to ensure that we are not calling code which is not thread-safe when we have assumed it is. This is something that is generally not easily picked up by either static analysis or software compilers.

Posted on

Spring Webflux: EventLoop vs Thread Per Request Model

Spring Webflux Introduction

Spring Webflux has been introduced as part of Spring 5, and with this, it started to support Reactive Programming. It uses an asynchronous programming model. The use of reactive programming makes applications highly scalable to support high request load over a period of time.

What Problem It Solved Compared With Spring MVC

Spring MVC uses a Synchronous Programming model, where each request has been mapped to a thread and which is responsible to take the response back to the request socket. Cases where applications make some network calls like, fetch data from a database, fetch a response from another application, file read/write etc., a request thread has to wait to get the desired response. 

Posted on

Troubleshooting the Performance of Vert.x Applications, Part I – The Event Loop Model

This article is the first in a series of three articles which share my experience with troubleshooting the performance of Vert.x applications. The first article provides an overview of the Vert.x event loop model, the second article covers techniques to prevent delays on the event loop, and the third article focuses on troubleshooting of event loop delays.

Programming with Vert.x requires a good understanding of its event loop model. From what I saw in practice, delayed or blocked event loop threads are the number one contributor to performance problems with Vert.x applications. But don't worry. In this article, we are going to review the event loop model.