<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Bjorn van der Laan on foojay.io - Friends of OpenJDK</title><link>https://foojayio.github.io/website/today/author/bjorn-vdlaan/</link><description>Articles written by Bjorn van der Laan on foojay.io - Friends of OpenJDK</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 09 Dec 2021 14:03:28 +0000</lastBuildDate><atom:link href="https://foojayio.github.io/website/today/author/bjorn-vdlaan/index.xml" rel="self" type="application/rss+xml"/><item><title>Non-blocking with Spring WebFlux, Kotlin and Coroutines</title><link>https://foojayio.github.io/website/today/build-and-test-non-blocking-web-applications-with-spring-webflux-kotlin-and-coroutines/</link><pubDate>Thu, 09 Dec 2021 14:03:28 +0000</pubDate><guid>https://foojayio.github.io/website/today/build-and-test-non-blocking-web-applications-with-spring-webflux-kotlin-and-coroutines/</guid><description>&lt;p&gt;When a HTTP request comes in, a &amp;rsquo;normal&amp;rsquo; web application would map the request to a specific thread from the thread pool. This assigned thread stays with the request until a response can be returned to the request socket. Along the way, we might need to fetch data from some web service or database, read or write to a file or do other I/O calls, during which the thread is blocked and has to wait until it gets a response. For applications with high request rates, the thread pool can at some point become exhausted and then no new requests can be handled anymore.&lt;/p&gt;</description></item></channel></rss>