In Distributed Computing Why a Receive call cannot be asynchronous?
Actually, it can. See NIO in Java for example.
Related
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
E.g. I want to call the #Asynchronous fire-and-forget method of service.
Are there any guarantees of "firing" of this method?
What will happen e.g. when server is stopped before actual firing of #Asynchronous method?
Will it be fired on the next start of application?
Is it possible to use other than the thread-pool implementation of #Asynchronous?
Can it act as JMS queue (in persistent way)? Should I use JMS for persistence?
Seems that we can't use #Asynchronous in any reliable system, because it doesn't provide guarantee of firing...
P.S. One possible option is to use persistent Timer's to make deferred calls. Is it good idea?
There are no transactional or persistence guarantees for #Asynchronous methods. I agree that this makes fire-and-forget methods very limited. I do think persistent timers are a reasonable alternative for asynchronously executing work if you need to guarantee it will run.
I want to make a call to a database which has lots of data and it might take a while to return.
I plan to do that work inside a call to Akka.future(f) and use an Async{} to render the response when the work is done.
Does it make sense to do that, or should I just do the long database call in the controller, without sending the work to Akka?
Or is there a way to do non blocking database access?
If you're forced to use a blocking driver for your database (if for some reason the async driver for MySQL doesn't work out) consider setting up an Actor pool (using routing) with a PinnedDispatcher.
The PinnedDispatcher provides a thread per actor and, by setting up the router, will give you the ability to adjust the number of threads strictly responsible for handling the database calls. Easy scaling. Also, by using Actors you can structure the messages between actors (e.g. a message having the results of the database call) a little easier.
You can use Akka.future(f) and provide your own Akka configuration file to get more threads to process your database accesses. Look at this config file for example.
But you pointed it out: the real problem is in using a database driver that blocks. I don't know which DB you are using, but it's worth to take a look to MongoDB with ReactiveMongo for example. With ReactiveMongo all MongoDB operations are perfectly non-blocking and asynchronous. There is a good introduction here. Moreover, it deals very well with Play Framework (check the ReactiveMongo Play Plugin).
EDIT: You can also check "Configuring Playframework's internal Akka system" to tune the worker threads number.
If the response is blocked on completion of the database call, then it's only useful to make it asynchronous if you can get other work done towards assembling the response while the call runs.
Non blocking database access could mean a couple different things: A client library that gives you a callback based API, which would be pretty similar to the future solution, or one that uses non-blocking sockets to save on thread usage. I'm assuming you mean the former, in which case I think it'd be functionally equivalent to using a future.
I was wondering what is should do in my case. I have to get data from a rest server and display it on my application. The UI for this is a webview and if no data is received from the server then there is nothing to display on the screen. In this case do i use an async request or a sync request? Also my other question is what is the difference between an async request as opposed to sync request on a seperate thread? (I thought thats what async does anyway).. ANy help would be greatly appreciated. Im a newbie to ios.. Thanks
You should always use asynchronous loading of network requests. Never block the main thread waiting for a network response.
Asynchronous can be either synchronous on a separate thread, or scheduled in the run loop of any thread.
Hope this helps!
The difference between Asynchronous and Synchronous is that Synchronous is the more efficient method of PC communication. However Asynchronous is the most common method of communication used for email applications, internet access and networking. Synchronous is usually used for transmission of large data bocks.
The network lib I'm writing needs to send and receive messages through a TCP socket. Messages can be sent or received any time, i.e should work as a full duplex channel.
I was able to implement such scenario using two threads: main thread calling send() and a dedicated thread mostly blocked at recv() call.
My question is: is it possible to implement the same scenario with a single thread? I.e. by registering some callback function?
As a side note: I need implement this scenario in C++, Java and Python.
Yes, it possible. You need to use an API that allows multiplexed I/O. Under C/C++ and Python you can use select() and non-blocking I/O, so that the only networking call you ever block in is select(). There is also poll() and epoll() and a number of other similar APIs that accomplish the same thing, with varying degrees of efficiency and portability. Java has non-blocking I/O APIs also.
Another possibility is to use asynchronous I/O, where you tell the OS to start an I/O transaction and it notifies you (by some mechanism) when it has finished the operation. I'm not familiar with that style of network programming, however, so I won't try to give details.
In general, a library would do this by providing an interface into the application's main loop / event loop.
For example, most single-threaded network-using applications would have a main loop that blocks in select(), poll() or similar. Your library would just return a file descriptor that the application should include in its select() / poll() call, and a callback function that the application should call when that file descriptor is readable.