I'm a newbie to Spring Reactive Modules. What I got is basically, at its core it enable reactive programming and we can develop end to end reactive service.
But, suppose I just want to make my controller as Async, so that I can do work on multiple threads and send a reply like "Task Started" (not particularly this) and have my work going on and close the HTTP link.
I also got to know about #EnableAsync and #Async to make a method Async.
What if I just use #Async above my controller method that I want to make async. It worked but, is this a good practice? And can we use this in production codes?
I do not see any problem using #Asyncas this will release the request thread. But this is a simple approach and it has a lot of limitations. Note that if you want to deal with reactive streams, you do not have an API capable of that. For instance, if an #Async method calls another, the second will not be async.
The Webflux instead will bring the most complete API (in Java) to deal with things the reactive way. What you cannot do with only #Async. With Flux, for instance, you can process or access with multiple layers reactively and this you cannot reach the way you doing.
Nevertheless, it will bring a new universe for you, so if you just want to release the thread of the request, your approach is just fine, but if you need more you will have to deal with it in a more complex way.
Now, if you want to answer the HTTP request and then do the work asyncly, this is not what you want. I recommend that you have a JMS provider (like ActiveMQ), where your controller sends the message to be processed by a job and answers the request.
Hope it helps!
Related
Let's say that while the API doing the work on backend, the http request consumer got disconnected. Therefore, database is updated but the consumer application doesn't know about it.
Is this scenario possible?
How can such a case be tested?
I think it is certainly a possibility.
The first thing I would try is to make the client-expected response from the API nothing in order to simulate such a scenario.
Yes, it's possible and common, your client need consider this situation. Also that's one of the reasons to use RESTful API, because it is stateless.
There's several ways to simulate such a scenario, one of them could be to put a sleep timer on your backend method so you manually disconnect or close the client, or it may reach timeout as well.
Is it possible for a RestTemplate to consume an endpoint which is reactive based (Spring WebFlux)? I understand that the main idea of reactive programming is to avoid blocking and make better use of threads (eliminate thread per connection model) so what happens if my Client is non reactive?
Will I still be able to call the service even if it is in a blocking
manner?
To achieve full reactiveness (non blocking) both Client and Server
must be reactive?
Yes, that is not relevant to the clients of Reactive applications. The reason is that this is a regular HTTP call.
Each may be fully reactive on its own. Having said that, if you use WebFlux in both Client and Server you will have a system that is as a whole reactive. But there is nothing forcing you to do this. You can have only one of the services as a Reactive application. It comes down to your needs and context.
We have a flow which we would like to implement with Reactive programming using Spring Boot 2 WebFlux. Currently we have no experience with Reactive programming.
As part of this flow we are going to create on or more HTTP requests (I guess using WebClient) and also read some data from DB.
We are considering to use AWS DynamoDB but as far as I understand the Java SDK does not support reactive API. This read will be a blocking I/O operation, my question is whether there is a benefit for implementing part of this flow with WebFlux? More generally, does a single blocking I/O operation in the flow eliminates all the benefit that we get from implementing with reactive programming?
Based on your question reactive is the idle way to deal with blocking operation especially IO (network, file and etc...)
you can use a library that implements this api in a reactive way or wrap a blocking request with a reactive api, this usually done by placing the blocking op on anther thread pool
in spring webflux you can achieve something similar like
#GetMapping
public Mono<Response> getResponse() {
return Mono.fromCallable(() -> blockingOp())
.publishOn(Schedulers.elastic());
}
publishOn in that case will cause all this flow to happen on another thread, you can choose dedicated thread pool as your choice
from the docs, elastic is a
Scheduler that dynamically creates ExecutorService-based Workers and caches the thread pools, reusing them once the Workers have been shut down.
The following may not answer your question fully, but might be a little helpful. There is a question mentioned in the FAQ for the Spring Framework 5, which is,
What if there is no reactive library for my database?
The answer to this is:
One suggestion for handling a mix of blocking and non-blocking code
would be to use the power of a microservice boundary to separate the
blocking backend datastore code from the non blocking front-end API.
Alternatively, you may also go with a worker thread pool for blocking
operations, keeping the main event loop non-blocking that way.
I think someone from Pivotal might be the right person to give more insights on this.
I am using Spring Boot, and I have a POST endpoint which needs to do various things such as persist an object to the database, and then also call 3-4 other services. However, I'd like to return a response shortly after the database call is persisted and then call the other services on another thread, asynchronously? The call to the other 3-4 services are okay to be eventually consistent (e.g. call to keen.io analytics service). How is this easily doable in Spring Boot?
I think that you do not even need spring for this job. You could use java.util.concurrent.CompletableFuture#runAsync to run sth async on a different thread.
Also you could use the spring async support. Just annotate a spring bean method (in your case returning void) with #Async. And do not forget to enable async support by annotating a configuration class with #EnableAsync.
One solution is to have a thread running that is monitoring a queue to determine when to execute some work. When a request has completed its immediate task then it would add information to the queue so that the monitoring thread can understand that it needs to do some work. You could have a pool of threads monitoring the queue to improve performance. This is a fairly standard pattern for event based programming which offers ability to have actions run async.
I'm experimenting with grails in order to interface with an online trading platform.
specifically Interactive Brokers (IB) http://interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
The way the API works is you need to have their client program, Trader Workstation (TWS http://interactivebrokers.com/en/p.php?f=tws&ib_entity=llc) running and then we consume the API to do stuff. Consuming the API basically involves creating a "broker" object, calling a connect() member function (this makes a local port connection to the TWS software) and calling something like getData()
The value of grails in this scenario are the GORM features and the web framework provided. I want to be able to define objects abstracted from db implementation, easily do persistance operations and easily provide users with a UI to do CRUD and custom actions.
My challenge is the IB API uses asynchronous communication for requests and replies. i.e. when i call getData(), the API knows to use the callback function dataResults() when it is ready to send them. In order for dataResults() to be callable, the broker object I created still needs to be around to receive the reply.
Inside a controller function, if i create a broker object and call getData(), when the request finishes, the broker object obviously also disappears. So I'll never be able to receive the reply.
I think there might be some way to do this by kicking off background threads but i'm not sure this is the path i want to go down.
Does anyone have any recommendations on what the best approach is?
I'm not married to grails, the reasons i'm using it are above. If there is a desktop app framework that I can also easily make a web interface on top of later, I'm definitely open to that.
thanks in advance.
Create your object in Service and make the Service singleton (which is by default):
static scope = "singleton"
In terms of web UI Grails is definitely a good choice.
Then, the asynchronous operations could be handled by Ajax calls as you shouldn't block the controller waiting for results.
The following [presentation][1] has some good examples
1: http://skillsmatter.com/podcast/java-jee/high-volume-scalable-ajax-with-grails