Because your threads are blocking my performance.
Non-Blocking I/O has been around for a while. Different languages implement it differently, but all provide a way to reduce the thread count while seeming to allow full concurrency. JavaScript has been doing it from the start; with only one thread, you better not be the coder that pushes a blocking call into production.
While reactive Java is gaining some traction, most Java coders I know still live in a multi-threaded frame of mind. Why? Threads are a relatively easy concept to grasp. Reactive Java requires us to rethink a lot of how we learned to code. …
And deploying the library to accomplish it to Maven Central.
This is a follow-up to my previous article Dealing with Exceptions in Functional Java and a bit of eating my own dog food from my article Sharing is Hard. At the end of Dealing with Exceptions in Functional Java, I indicated where there were still some lambda types missing and I wasn’t planning on trying to implement them. But fate had other plans for me.
After writing Sharing is Hard, I decided to tackle a new process, that of pushing something to Maven Central to be sharable by all. It turned out to be relatively easy, the hardest part was…
Throwing exceptions like a pro
Exceptions used to be very handy. When your application was broken down via functional decomposition, bubbling up exceptions to some level where they could be reasonably handled was important. Functional decomposition could lead to pretty deep nesting, and handling problems at each level was a major problem and source of errors.
With functional programming, functional decomposition is often replaced by action-based decomposition. You have specific action patterns such as map and filter that are chained together and your functions provide the specifics of each action. …
But not sharing is harder
We all learn to share as children, so why is it so hard for developers? Everyone says DRY (don’t repeat yourself) and yet how many times do two developers write duplicate code? Let’s face it, there’s a lot of very wet developers out there. We have to accept the fact that sharing code is hard.
There are a lot of reasons why sharing code is hard. People don’t always trust other’s code, developers like to develop, or we don’t even realize the code was already available elsewhere. …
The unique relationship of the Optional and Stream types.
Lately, I’ve been doing a lot of work with Project Reactor and their two main types, Mono and Flux. The main difference between a Mono and a Flux is that a Mono can only represent zero or one element, while a Flux can represent zero or infinite elements. Also recently, I really latched on to the similarity between Mono and Flux and the Java Optional and Stream types. In fact, as of Java 9, you can convert an Optional to a Stream using the stream() method.
For those of us that have trouble fully utilizing the Optional type as intended…
Authentication vs Authorization
It’s been a while since I last wrote about this project. My Kubernetes server had a meltdown and I had to go through the process of setting it all up again. This time I stuck with a premade solution, MicroK8s as described in Exposing your Home Server to the Big Bad Internet. The ingress is hooked up directly to the Internet and SSL is handled through Cloudflare. Also, the volume claims are direct disk access since MicroK8s is a one-node cluster. The new Kubernetes description files are still in my GitHub repository blackbook-deploy.
Ensure coherent logging across multiple threads.
There are lots of Java logging libraries and facades and I’m sure everyone has their favorite. One thing that many have in common is the MDC facility to provide logging with context. So if your service has some kind of event id that you want to add to logs, you can use the MDC.put(“eventId”, eventId) to ensure that all of the logs dealing with that event will print out the event id.
The problem occurs because it assumes that the processing for an event all occurs on a single thread, although there may be…
Taking advantage of Project Reactor’s hybrid model of threading/non-blocking.
In Node.js and JavaScript in general, there is only one thread (though I think newer versions of Node.js allow threading?). This brought about a whole ecosystem of how to deal with asynchronous calls, from async/await to basic promises and lower-level call-backs. When Java got on board with Non-Blocking asynchronous handling through frameworks such as Project Reactor, it stuck with a hybrid model of Non-Blocking I/O and Threads to achieve concurrency. Threads are so baked into the Java pie, there is no way to get rid of them.
But Project Reactor presents a very rich set of ways to deal with…
What the Flux?
In my last article, Understanding Reactive Java, I created a simple demonstration of a lot of the power of reactive Java. The tiny application I created represented a set of microservices that processed induction of used vehicles according to type. The input was a simple purchase order type, and it produced Car, Motorcycle, and Truck types for further processing.
The idea of reactive Java is that you create a chain of processing that allows the system to schedule non-blocking tasks and to divide up blocking tasks into input and output tasks. …
A functional implementation of the Bakhshali method of approximating square roots
In a previous article, Rethinking Structured Programming, I talked about using Streams and Reactive functional programming in Java to act as the control structures in structured programming. I described one problem that I thought couldn’t currently be solved with the features of Streams or Fluxes: if the output of a function was the input of that same function iteratively. This describes a special type of recursion — tail-recursion — that can be changed into a loop. But in all of my examples, the output of one stage was always the input of the next stage. …
Randal Kamradt Sr
Software dev for thirty years still keeping on top of the latest tech trends. I write about the learning process. https://rkamradt.github.io/
