Develop Reference

Quarkus reactive vs quarkus imperative does it matter?

Hello I was reading the following article Quarkus reactive architecture
At the start of the article it says
Quarkus is reactive. It’s even more than this: Quarkus unifies reactive and imperative programming. You don’t even have to choose: you can implement reactive components and imperative components then combine them inside the very same application.
just below the middle the article mentions
Thanks to hints in your code (such as the #Blocking and #NonBlocking annotations), Quarkus extensions can decide when the application logic is blocking or non-blocking.
My questions is does it matter if i write reactive or imperative? For example
Reactive approach
#GET
public Uni<List<Fruit>> get() {
return sf.withTransaction((s,t) -> s
.createNamedQuery("Fruits.findAll", Fruit.class)
.getResultList()
);
}
Imperative approach
#GET
#NonBlocking
public List<Fruit> get() {
return entityManager.createNamedQuery("Fruits.findAll", Fruit.class)
.getResultList();
}
Will both these code snippets run with the same reactive benefits?

Assuming your second snippet uses classic blocking Hibernate ORM, it will not work just like the first snippet (which seemingly uses Hibernate Reactive). It contains a blocking call, so you will block the event loop, which is the worst thing you can do in a non-blocking architecture, as it basically works against all the benefits that a non-blocking architecture can give you (see https://vertx.io/docs/vertx-core/java/#golden_rule).
If your methods are blocking, which includes calls to other libraries that are blocking, you must not pretend that they are #NonBlocking. If you remove the #NonBlocking annotation, the method call will be offloaded to a thread pool and the event loop stays free to handle other requests. This has some overhead, plus the thread pool is not infinite, but I dare to say that it will work just fine in a vast majority of cases.

Async template deployments with Java AzureResourceManager

I'm writing a service that submits ARM templates to spin up various Azure resources via the Azure Java client API, for example:
Mono<Deployment> deploymentMono = arm.deployments()
.define(deploymentName)
.withNewResourceGroup(resourceGroup, Region.US_WEST2)
.withTemplate(templateJson)
.withParameters(parametersJson)
.withMode(DeploymentMode.INCREMENTAL)
.createAsync();
I want to run it in Azure Functions, but some of these deployments take a long time.
Ideally I'd like to submit a deployment and get back an immediate ok (or error) from the server, with an ID I can use to check the status later. However I only see these options with the client API:
Use create() and block for the whole thing to finish (obviously not what I want).
Use createAsync() and wait for an event. However the only events that look useful are doOnSubscribe (which is called too early), and doOnNext (which isn't called until after the whole thing completes).
I can call subscribe() and then poll the deployment state:
Deployment deployment = arm.deployments().getByResourceGroup(resourceGroup, deploymentName);
if (deployment.provisioningState().equals("Running"))...
but it seems like I must be missing something. There's got to be a method that lets me just submit an ARM template, get confirmation that the Resource Manager is doing its thing, and not wait around for completion, right?

I found it - it's the beginCreate() method on the Deployment.DefinitionStages.WithCreate interface.
Boy, I really hate fluent APIs sometimes. Having docs spread out over 50 objects when you could have a few simple factory methods isn't a step forward in usability, imho.

Java - Thread.sleep VS Awaitility.await()

Happy Friday everyone,
I'd like to replace Thread.sleep with Awaitility.await(),ideally with minimal changes, as I'm going over Sonar bugs in an older repository. I'm attempting to avoid usage of until of Awaitility, and it is not working out. I understand Awaitility is for async behavior and until function is a big part of it. I'm hoping someone with more experience with Awaitility could suggest a clean usage of it in this test scenario, much appreciate your input.
//Thread.sleep(1000);
Awaitility.await().atMost(Duration.ONE_SECOND);
list = client.getLocation();
Assertions.assertFalse(list.isEmpty());

Despite your intention, I encourage you to give Awaitility and until() another try. The example below test the same thing in a single one-liner (albeit it is written in several lines for improved readability):
#Test
void test_refresh() {
Awaitility
.await()
.atMost(5, TimeUnit.SECONDS)
.until(() -> {
List<Trp> trpList = client.getAllTrps();
return !trpList.isEmpty();
});
}
For more fine grained control of the polling you can take a look at methods like pollInterval() and pollDelay().

Though what you did can make sense from the first look, but with a better understanding of the design of the library there are two apparent principles that you have missed.
The Awaitility library introduces a functional style usage to define properties, conditions, accumulators and transformations.
1. Terminal Operations.
Awaitility
.await()
.atMost(Duration.TWO_SECONDS)
The above code will not execute, because internally what runs the chain is a call to Condition#await which is accessed only by caling ConditionFactory#until.
This call to until can be called a Terminal Operation
2. Intermediate Operations.
Operations like await, atMost , timeout and other operations only return the same instance of ConditionFactory, which will only define behaviour and actions in a lazy manner.
So in a nutshell the design expects you to:
Create an instance of ConditionFactory using Awaitility#await.
Define your await behaviour using the intermediate methods.
Execute and/or transform using until and its variants.

Vertx3 - Return a value from a JDBC connection? (sql db).

I have an interface with a single method that returns "config" Object.
I want to utilize interface this in Android and Vertx3 environments.
Config retrieveConfig(String authCreds);
I'm trying to implement this in a vertx program, utilizing the JDBC client from it, but I'm running into issues.
jdbcClient.getConnection(sqlConnResult ->
//checks for success
sqlConnResult.result().query(selectStatement, rows -> {
//get result here, want to return it as answer to interface.
//seems this is a "void" method in this scope.
});
Is this interface even possible with Vertx async code?

In Async programming you can't really return your value to the caller, because this would then be a blocking call - one of the main things async programming seeks to remove. This is why in Vertx a lot of methods return this or void.
Various paradigms exist as alternatives:
Vert.x makes extensive use of the Handler<T> interface where the handler(T result) method will be executed with the result.
Vert.x 3 also has support for the Rx Observable. This will allow you to return an Observable<T> which will emit the result to subscribers once the async task has completed.
Also, there is always an option to return Future<T> which, once the async task has completed will contain the result. Although Vert.x doesn't really use this very much.
So you're probably going to find it difficult to have a common interface like this for blocking and non-blocking api. Vertx offers nice and easy ways to run blocking code but I don't think that is a good solution in your case.
Personally, I would have a look at RxJava. There is support for Rx on Android, and has been well adopted in Vertx 3 - with almost every API call having a Rx equivalent.
Moving from:
Config retrieveConfig(String authCreds);
to
Observable<Config> retrieveConfig(String authCreds);
would give you the ability to have a common interface and for it to work on both Android & Vert.x. It would also give the added benefit of not having to stray into callback hell which Rx seeks to avoid.
Hope this helps,

What's the level of asynchronism in Play! framework

Play! touts its asynchronous HTTP handling feature, though it is not very clear to me what else are truly async (non-blocking and without thread switching.) In the asynchronous examples I read, like the one below taken from the Play! Framework Cookbook:
public static void generateInvoice(Long orderId) {
Order order = Order.findById(orderId); // #a
InputStream is = await(new OrderAsPdfJob(order).now()); // #b
renderBinary(is);
}
They focuses on the long/expensive "business logic" step at #b, but my concern is at the DB calls at #a. In fact, majority of the controller methods in many apps will just try to do multiple CRUD to DB, like:
public static void generateInvoice(Long orderId) {
Order order = Order.findById(orderId); // #a
render(order);
}
I'm particularly concerned about the claim of using "small number of threads" when serving this DB access pattern.
So the questions are
Will Play! will block on the JDBC calls?
If we wrap such calls in future/promise/await, it will cause thread switching (besides the inconvenience due the pervasiveness of DB calls,) right?
In light of this, how does its asynchronism comparing to a servlet server with NIO connector (e.g. Tomcat + NIO connector but without using the new event handler) in serving this DB access pattern?
Is there any plan to support asynchronous DB driver, like http://code.google.com/p/adbcj/ ?

Play will block on JDBC calls--there's no magic to prevent that.
To wrap a j.u.c.Future in an F.Promise for Play, a loop is needed. This can result in a lot of context switches.
Servlet containers can use NIO e.g. to keep connections open between requests without tying up threads for inactive connections. But a JDBC call in request handling code will block and tie up a thread just the same.
ADBCJ implements j.u.c.Future, but also supports callbacks, which can be tied to an F.Promise, see https://groups.google.com/d/topic/play-framework/c4DOOtGF50c/discussion.
I'm not convinced Play's async feature is worthwhile, given how much it complicates the code and testing. Maybe if you need to handle thousands of requests per second on a single machine while calling slow services.