In the video below, we take a closer look at how to get a record from the database using JdbcTemplate with Spring Boot. Let’s get started!
Articles
In the video below, we take a closer look at how to insert a record in the database using JdbcTemplate with Spring Boot. Let’s get started!
In the video below, we take a closer look at Spring Boot JMSTemplate with Embedded ActiveMQ. Let’s get started!
In the video below, we take a closer look at Spring Auto-Wiring Beans with @Autowired annotation. Let’s get started!
This article describes the steps that need to be followed in order to invoke a stored procedure with complex Abstract Data Type as IN, OUT, and IN OUT parameter in Mule 4.
The lack of documentation to handle ADT payloads while invoking stored procedures and technical issues while retrieving the ADT response in mule run time 4.x.x discouraged developers using mulesoft for the purpose.
This article is for the Scala programmer who has at least used or heard about Futures before. You can also find this over at the Rock the JVM blog or on YouTube in video form or embedded below:
In this article, I’m going to address the problem of "deterministic" Futures in Scala. You probably know by now that Futures are inherently non-deterministic, in the sense that if you create a Future
Scala
xxxxxxxxxx
1
1
val myFuture = Future {
2
// you have no future, you are DOOMED!
3
42
4
// JK.
5
}
You know the value inside will be evaluated on "some" thread, at "some" point in time, without your control.
The Scenario
Here, I will speak to the following scenario which comes up often in practice. Imagine you’re designing a function like this:
Scala
xxxxxxxxxx
1
1
def gimmeMyPreciousValue(yourArg: Int): Future[String]
2
with the assumption that you’re issuing a request to some multi-threaded service which, is getting called all the time. Let’s also assume that the service looks like this:
Scala
xxxxxxxxxx
1
1
object MyService {
2
def produceThePreciousValue(theArg: Int): String = "The meaning of your life is " + (theArg / 42)
3
4
def submitTask[A](actualArg: A)(function: A => Unit): Boolean = {
5
// send the function to be evaluated on some thread, at the discretion of the scheduling logic
6
true
7
}
8
}
The service has two API methods:
-
A "production" function that is completely deterministic.
-
A submission function that has a pretty terrible API because the function argument will be evaluated on one of the service’s threads, and you can’t get the returned value back from another thread’s call stack.
Let’s assume this important service is also impossible to change, for various reasons (API breaks, etc). In other words, the "production" logic is completely fixed and deterministic. However, what’s not deterministic is when the service will actually end up calling the production function. In other words, you can’t implement your function as:
Scala
xxxxxxxxxx
1
1
def gimmeMyPreciousValue(yourArg: Int): Future[String] = Future {
2
MyService.produceThePreciousValue(yourArg)
3
}
because spawning up the thread responsible for evaluating the production function is not up to you.
The Solution
Introducing Promises — a "controller" and "wrapper" over a Future. Here’s how it works. You create a Promise, get its Future and use it (consume it) with the assumption that it will be filled in later:
Scala
xxxxxxxxxx
1
1
// create an empty promise
2
val myPromise = Promise[String]()
3
// extract its future
4
val myFuture = myPromise.future
5
// do your thing with the future, assuming it will be filled with a value at some point
6
val furtherProcessing = myFuture.map(_.toUpperCase())
Then pass that promise to someone else, perhaps an asynchronous service:
Scala
xxxxxxxxxx
1
1
val asyncCall(promise: Promise[String]): Unit = {
2
promise.success("Your value here, your majesty")
3
}
And at the moment, the promise contains a value. Its future will automatically be fulfilled with that value, which will unlock the consumer.
How to Use it
For our service scenario, here’s how we would implement our function:
Scala
x
14
1
def gimmeMyPreciousValue(yourArg: Int): Future[String] = {
2
// create promise now
3
val thePromise = Promise[String]()
4
5
// submit a task to be evaluated later, at the discretion of the service
6
// note: if the service is not on the same JVM, you can pass a tuple with the arg and the promise so the service has access to both
7
MyService.submit(yourArg) { x: Int =>
8
val preciousValue = MyService.producePreciousValue(x)
9
thePromise.success(preciousValue)
10
}
11
12
// return the future now, so it can be reused by whoever's consuming it
13
thePromise.future
14
}
We create a promise and then we return its future at the end for whoever wants to consume it. In the middle, we submit a function that will be evaluated at some point out of our control. At that moment, the service produces the value and fulfills the Promise, which will automatically fulfill the Future for the consumer.
This is how we can leverage the power of Promises to create "controllable" Futures, which we can fulfill at a moment of our choosing. The Promise class also has other methods, such as
failure, trySuccess/ tryFailure and more. I hope this was useful!
Despite Java not providing a zip operation, you don’t need either 30 additional lines to implement it, nor a third party library. Simply compose a zipline through the existing Stream API.
Abstract
Java, from its 8th version onward, provides an easy way to query sequences of elements through its Stream Interface, which provides several operations out of the box. This set of operations is quite versatile but, as can be expected, it does not cover all the operations a programmer may require. One such operation is zip, as we can observe in one of the most visited posts about Java Streams in Stackoverfow: Zipping streams using JDK8 with lambda (java.util.stream.Streams.zip). Even 7 years later, we are now on Java 14 release and there is no zip operation for Streams yet.
Apache Ignite as a distributed database and caching platform needs end-to-end monitoring to act on time. Historically, Apache Ignite provides a set of API and instrumentation to gather application-specific information and metrics by the external tools. In release 2.8.0, Apache Ignite improved the monitoring capabilities and introduced some nice features like "System views subsystem" and "Metrics subsystem."
In this short article, we are going to explore the Apache Ignite new monitoring opportunities and how to use different tools and technics to gather metrics for diagnosis. Anyway, the full release notes of version 2.8.0 can be found here.
Health checks are a fundamental part of our APIs. I guess they fall in that category of "non-functional-but-heavily-required" things. More or less like a good part of the infrastructure code.
They don’t add business value per se but have an enormous impact for those in IT, like DDD and design patterns. You can normally see them in conjunction with container orchestration or monitoring tools to ensure that the system is alive and kicking.
