My question is very simple in Java reactive programming
Thread Model:
User A (Lets say Thread 1), sends GET request to application.
Thread 1 will wait/blocked until it gets response from DB(IO request).
Once response received, block is removed and Thread_1 returns response to user.
Reactive Programming model:
User A (Lets say Thread 1), sends GET request to application.
In reactive thread_1 will have one call back to run. So it won't wait/blocked.
Question:
Who will run that call back? That is, which thread will run that call back?
What is event loop mechanism in reactor? Provide example in layman terms.
How to make use of multiple core CPU in reactive programming for NIO tasks?
Spring WebFlux has an event loop thread group which by default consists of as many threads as many CPU cores the machine running the application has. The callback is run by one of the threads from the group. If you use Spring WebFlux and WebClient (or any other reative data access library) then you get this multi-threaded behaviour out of the box.
Related
What is the most appropriate ProjectReactor Processor to use with the following use case:
Say the core function of the game service has 10 rest calls. After each of those call's purpose/activity is complete, we need to update the users score. There's a separate User Score service that tracks each users score. Most importantly, we want the User Score service calls to be asynchronous and not block the response to the 10 calls supporting the game. In other words, only after (or asynchronously) the core rest controller methods to return their data to the caller, should the updates to the User Score service happen.
The rest controller is built using Spring Webflux, and all calls require network resources (database or other service calls), so are subscribed on the elastic scheduler. As such, the events will be produced from different threads, thus this is a multi-threaded source.
Consuming the events from the Process's stream should be asynchronous as well, with perhaps a way to limit the concurrent requests so that we can prioritize the response to the 10 main calls, instead of updating scores.
I am going to keep it short, we have a product that uses BPM and internal queue with lots of EJBs (pojo implementation). We decided to add REST to the product and we zeroed in to JAX-RS and Swagger for documentation.
Now, we created endpoint pointing to a async scenario in a such a way that when REST request arrives we start the BPMN flow asynchronously and then we wait for agreed timeout duration for flows to finish so that we can parallelly send a response to internal queue, which receive message when BPMN flow finished processing and then can construct REST response.
I am looking for some enterprise pattern or some utility framework to help me achieve this and not invent it myself. I know Camel has lots of such patterns but I am not so sure I am looking for something available on JDK 1.6 compatible framework to simulate this synchronous behavior.
I would have something like a RxJava or some observer notifier pattern probably no internal JMS queues to pass message between threads. A concurrent and thread-safe soilutuion is what I am looking for.
I would have something like a RxJava or some observer notifier pattern probably no internal JMS queues to pass message between threads. A concurrent and thread-safe solution is what I am looking for.
If you are to be using JAX-RS, then you should probably become familiar with the Asynchronous Server API. For a slow but synchronous operation, you would simply dispatch a task to your executor, and resume the suspended request when you have a result.
Another approach is to store the suspended request in a shared data structure, with a worker responsible for observing the completed flows, looking up the suspended request and dispatching the response.
The ResponseServlet from Michael Barker's ticketing demonstration shows this basic idea (Barker's code uses servlets rather than JAX-RS, and Disruptor rather than RxJava, so you'll need to translate).
Additional resources on async response processing
https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-2rd-edition/content/en/part1/chapter13/server_asynchronous_response_processing.html
http://www.nurkiewicz.com/2014/12/asynchronous-timeouts-with.html
I am trying to use Akka to implement the following (I think I'm trying to use Akka the proper way):
I have a system where I have n resource listeners. Essentially a resource listener is an entity that will listen on an input resource and publish what it sees (i.e. polling a database, tailing a log file, etc.).
So I want to use Akka actors to do these little bits of work units (listening on a resource). I've noticed that the Akka gives me a thread pool of t threads which may be less than the number of listeners. Unfortunately for me, getting a message from these resource listeners might be blocking, so it could take seconds, minutes, before the next message pops up.
Is there any way to suspend a resource listener so it leaves the thread to another actor and we'll come back to it a little later in time?
Executive Summary
What you want is for your producer API (the resources) to be asynchronous, or at least support non-blocking operations (so that you can do polling). If the API does not support that, then there is no way to retrofit this property, not even using the almighty actors ;-)
Strategies for Different Situations
Only Blocking API
If the resources only support the blocking getWhatever() method of retrieving things, then you must allocate one thread per resource. An Actor with a PinnedDispatcher could be a way to do this. But be aware that the actor will not be responsive while waiting for events from the resource.
Non-Blocking but Synchronous API
If there is a peek() or poll() method on the resource API, you can use one actor per resource, have them share a thread (or pool) and schedule the polling as required (i.e. every 100ms or whatever you need). This has the huge advantage that nobody is actually blocked and the whole system remains responsive. But latency for event reception will be of the order of your schedule interval.
Proper Asynchronous API
If you have enough good karma to encounter a nice asynchronous API, then simply register a callback which will send a message to the actor whenever an event occurs. Sadly, this is not the norm.
PS:
The JVM does not support wrapping up the current call stack, doing something else and return to that same processing state later. A method can only be popped of the stack when it is actually finished.
In general, you should try to avoid blocking operations in actors. For file IO, there are asynchronous libraries and for some databases, too. If that is not an option for you, you can set change the default dispatcher so that the underlying thread pool expands as needed.
One option is to call your blocking APIs inside Futures. The Futures should use an ExecutionContext (thread pool) that is separate from the Actors' ExecutionContext.
See this blog post for an example (specifically CacheActor.findValueForSender).
I'm trying to setup Canon's EDSDK (for controlling Eos cameras), and it event handlers need to be handled by callbacks via the User32 Get/DispatchMessages api (in Windows at least).
The event dispatching needs to:
loop to continually dispatch messages
happen in the same thread as the SDK is initialised in
This basically requires a single threaded command reciever/message dispatcher thread as can be seen at kritzikratzi's edsdk4j library (the thread is set up in line 66).
So given that Scala has actors that are perfect for recieving messages (from multiple threads, which I could end up doing), what's the best way of going about making a single-threaded access to the Canon sdk and Windows User32 apis?
I'm completely open to (and interested in!) akka if that will help
ASP.NET MVC 2 includes the built in feature of asynchronous controllers. My question is: Is there any benefits on using the asynchronous controllers to send messages to the bus if I'm not waiting for a reply from the bus?
Microsoft states this in their async controller documentation:
In general, use asynchronous pipelines when the following conditions are true:
The operations are network-bound or I/O-bound instead of CPU-bound.
Testing shows that the blocking operations are a bottleneck in site performance and that IIS
can service more requests by using asynchronous action methods for these blocking calls.
Parallelism is more important than simplicity of code.
You want to provide a mechanism that lets users cancel a long-running request.
When reading through the list and keeping in mind that we're not excepting any reply from the bus, I'm not seeing any benefits on using the async controllers over the synchronous ones. But is there?
If you don't need the response then you don't need async controllers.