We are currently using an older version of Quarkus, so I would want to understand the impact and consider if we should upgrade to the latest version.
I learnt that since version 2.2 Quarkus will run method on I/O thread or Worker thread depending on the method return type (https://quarkus.io/blog/resteasy-reactive-smart-dispatch/#new-world-new-rules), meaning blocking/sync method not returning Uni/Multi/CompletionStage will be automatically offloaded to a worker thread so that it will not block the I/O thread.
In our current implementation with the older version of Quarkus and RESTEasy Reactive (I think it is 1.12.2), for all the methods not returning Uni/Multi/CompletionStage I believe they will get called on the I/O thread because we are not using #Blocking on them. These methods include actions such as calling external APIs, accessing databases and accessing files, etc, so I assume it should be our responsibility to do these actions in a non-blocking/async manner by using reactive libraries, otherwise they will block the I/O thread (Given that not all these methods I mentioned are currently implemented using reactive libraries). But upgrading to the latest version will fix this issue as such methods will be offloaded to worker thread, am I correct?
P.S: By reading Quarkus doc I understand that a minimal amount of I/O threads can handle many concurrent requests. I am curious by default how many I/O threads are there and is this configurable? Thanks!
You are correct in assuming that prior to Quarkus 2.2, the default for RESTEasy Reactive was to do handle the requests on the event-loop for all methods except when #Blocking was used.
It goes without saying that this means you need to not do any blocking IO (or have any long running operations for that matter) in these methods.
Quarkus uses 2*number_of_cpu_threads as the default number of event-loop threads it creates
Related
I'm trying to use kotlin coroutines with "old-style" Spring JPA repository.
I create a new coroutines scope and run all JPA calls in "async".
I see that even with non reactive JDBC I improve my throughput.
But I wonder, may be exists some coroutines wrapper on Spring JPA repository?
Something created with reflection and Spring "magic"?
First I'd like to clarify one thing to prevent a possible confusion:
If you're using Spring Data JPA, then you should know that this framework uses JDBC driver underhood, that is actually a blocking API, that means all the database calls make the calling thread block until the total result is completed and ready to be consumed.
Having that knowledge I presume you're using suspend functions with coroutines that run on Dispatcher.IO for making such calls.
This dispatcher provides you with one thread (as far as I know, it scales up to 64 threads) for each call. And that thread actually blocks while making your database call, which means coroutines and suspend does not make any magic in this kind of situation except for switching your blocking call to another thread (which eventually will be blocked).
Maybe you should take a look at r2dbc (reactive SQL driver) and use CoroutineCrudRepository<T, ID> from Spring Data instead of using standard JpaRepostitory<T, ID>.
CoroutineCrudRepository<T, ID> has all the methods with suspend which means you can use them for creating "truly" async API without blocking at all.
However, r2dbc may be not suitable for your use cases since it has a lot of limitations, such as mapping relations, caching and etc.
UPDATED:
As far as I know there is no Spring-way to automatically wrap blocking calls, but you can take a look at this library
I am very new to reactive programming, and currently working on microservice where in spring mvc is used and Spring Data MongoDb for database connectivity.
As I am going through spring data mongo db docs, there is support for reactive repositories, reative template api etc.
So Is there going to be any downside if I choose to use reactive templates and repository with blocking nature ?
Ex.
reactiveMongoTemplate.add(entity).block()
reactiveMongoTemplate.update(id, entity).block()
Also is there any significant difference with using calls like above than using blocking repository and template api itself ?
The answer depends on which stack you use: Spring WebFlux or Spring Web MVC.
In case of Spring WebFlux the choice is obvious: you have to use ReactiveMongoTemplate and never call block on it, instead return Mono/Flux as you get it from the template.
In case of Spring Web MVC you are free to use both the regular blocking MongoTemplate and ReactiveMongoTemplate with block. Although, in most cases you should go with the good old MongoTemplate for sake of simplicity and performance. ReactiveMongoTemplate has some overhead compared to the blocking MongoTemplate because the reactive types Mono/Flux put some additional pressure on memory.
I can imagine one use case where ReactiveMongoTemplate can provide some advantage even in Spring MVC: when during one HTTP request you have to execute multiple Mono operations concurrently. If you used blocking MongoTemplate then you would need to set up a thread pool and delegate the query execution there. However, with ReactiveMongoTemplate you could use the many operators of Mono and Flux to accomplish this task without worrying about threads, thread pools and scaling issues.
In the traditional programming you usually own the thread that you're running on, in the reactive programming its not the case. This "underlying unit of execution" (cpu resources consumer if you wish) is not yours, but rather a "global" thing that currently happens to execute your task, but can switch to do other things really soon.
So when you block, you say to this "global unit of execution" like "hey, stop doing anything else, wait for me". In the traditional approach, its kind of ok, because you have a thread associated with the current request, other requests (or flows if your system is not web based) are supposed to be executed with other threads taken from a fairly large thread pool. In the reactive system however, its not the case since you're trying to utilize a small amount of these "global units of execution".
Ok, so if you block, the events all over the place will stop emitting and will get start to buffer. And this may lead to the whole system becoming unusable.
Let's imagine a scenario where there's an old app written using Servlet stack and you decide to migrate it to a Spring Webflux. Let's also say that first thing to migrate is RestTemplate to WebClient.
What would be preferred way of handling Mono or Flux that WebClient returns? Calling block seems okay solution since app uses RestTemplate which blocks anyway. subscribe should be a bit nicer since it has a callback, but maybe you have to wait to be able to continue. Also, with subscribe, do we need to handle a Disposable and, if yes, how, because I'm not sure where is the best place to call dispose on it?
And one more question regarding JDBC. How dangerous is to use Schedulers.boundedElastic()? From my understanding, having a separate thread pool should help especially if Netty is used. It's not ideal, but could it be a temporary solution until R2DBC drivers reach 1.0.0? What if app uses Tomcat? Is the situation better since Tomcat by default has more threads?
What would be preferred way of handling Mono or Flux that WebClient returns?
Given you're aiming to use Webflux, the ultimate preferred way is to deal with these publishers the entire way up your reactive chain. This means you won't end up calling subscribe on anything directly, because your controller will itself return a Mono (and everything, including the WebClient calls, will just be incorporated into that Mono via a series of reactive opreations in the chain.)
However, as you point out, you can't realistically migrate everything at once.
If it's only the WebClient that you're migrating for now, then just call block() to treat it the same way as your RestController. There's no advantage with calling subscribe() and then waiting for the subscription to complete - that's just a less obvious and more long-winded way of blocking.
Once you migrate more and more of your stack to reactive, you can do more and more in a reactive fashion, and then start to "move" your block() calls further up the chain as a result (until the block is at the controller level, and then you can just switch over to returning the Mono.)
Also, with subscribe, do we need to handle a Disposable
Only if you need to potentially cancel the subscriber (and it supports it.) This is quite a rare occurance in my experience.
And one more question regarding JDBC. How dangerous is to use Schedulers.boundedElastic()?
boundedElastic() is designed to be a wrapper for blocking IO, so there's nothing inherently wrong with using that on the reactor side. The only "danger" would be on the JDBC / app side as to if it fits your requirements:
It's capped at 10x the number of CPU cores
The number of "queued" tasks is capped at 100K
If you've got enough long running DB queries that this isn't enough, then you might consider using newBoundedElastic() instead and specifying the threadCap and queuedTaskCap manually.
What if app uses Tomcat? Is the situation better since Tomcat by default has more threads?
I wouldn't advise relying on it. Tomcat still uses one thread per request (even with Webflux), so the danger there is you end up blocking on a thread you shouldn't, and end up not realising and then relying on that behaviour (which would then all come tumbling down when you switched to Netty.)
So I'm developing an application on top of Dropwizard and in one component I have to call an external rest service. I want to do it using JerseyClient.
Now there are 2 implementations available, the one from dropwizard and one from jersey. Using the Builder I have to choose between
io.dropwizard.client.JerseyClientBuilder.JerseyClientBuilder
and
org.glassfish.jersey.client.JerseyClientBuilder
Now the former requires Environment as well as JerseyClientConfiguration being passed to it.
Is there a good reason for using the dropwizard implementation over the vanilla one? What's the difference (except the timeout)?
Thank you
After some more digging and asking around, got an answer (below). It seems that it is better to use the JerseyClientBuilder that comes with Dropwizard as it is better integrated:
One can use JerseyClientConfiguration in order to configure the JerseyClientBuilder via the application configuration (service.yml file).
Passing the Environment information enables use of the managed thread pool that is integrated within Dropwizard's lifecycle, so when Dropwizard gets shut down, so does the client.
Dropwizard's Metrics get integrated into each client so you can see the latency and rate of calls for each one, as well as metrics around the thread pool sizes.
Is HTTPBuilder in Grails thread safe?
If HTTPBuilder is wired to a Grails service class, will it be safe to use? Or should it be instantiated on every invocation?
There doesn't seem to be any concrete answer as to whether HTTPBuilder in Grails is thread safe or not. I'm inclined to go with non thread safe due to the lack of documentation regarding that particular aspect, but I'd like a definitive answer.
The code seem to indicate it should be ok to handle multiple requests from multiple threads so long as they will go through to the same URL with the same context (headers, authenticators etc.).
Do you mean groovyx.net.http.HTTPBuilder? It has several fields that are modified by calling methods, and there's no synchronization or locking, and no use of thread-safe collections or other classes, so no, it's very much non-thread-safe. Most builders are similarly stateful and should be assumed to not be thread-safe.