Retrieving HTTP response without blocking the main thread - java

I am currently porting a networking library written in Objective-C to Java, and I need the functionality to make asynchronous HTTP requests to a server, without relying on any third-party libraries (so, no Apache dependencies). I am using HTTPUrlConnection to do this; however, as you know it is a synchronous process.
I am trying to implement concurrency into this process using the ExecutorService and Future<> structures. I need to use Callable instead of Runnable, because I need to process the response message the server sends back to me. Here is a small overview of what I am doing:
ExecutorService executorService = Executors.newSingleThreadExecutor();
Future<String> future = executorService.submit(new Callable<String>() {
#Override
public String call() throws Exception {
return postRequest(reqMsg);
}
});
where reqMsg is the request message (in XML), and the postRequest method returns the response message as a String (also in XML). Now, in order to retrieve the return value of this Callable task, I need to use future.get(). However, this method is a blocking call, meaning it blocks the main thread until a response is available. This is not what I want.
I am porting an iOS application to Android, and I am going to be using J2ObjC to have a cross-platform shared library between these platforms. In the iOS version (meaning the Obj-C version of the library), there are completion handlers that handle the results from HTTP request, and it is made asynchronously. Java, unfortunately, introduced this callback way of handling it in Java 8, with CompletableFuture. However, Android only supports CompletableFuture starting with API level 24. I want to be able to support API levels going back to Jelly Bean (API 16). And as far as I know, "for a JAR file to be compatible with Android, it can only reference classes available as part of Android and other classes implemented specifically in the JAR itself". You might suggest using AsyncTasks; however, I want to handle the concurrency of HTTP requests on the Java networking side, as this library will most likely be shared across two platforms.
I have tried using Threads explicitly; however, as I researched it, I found out that in order to use Callables, you need to use ExecutorService and Future (plus, there seems to be some performance overheads related to creating Threads explicitly - though I think an overhead of < 1000ms is acceptable). And again, just to reiterate (i.e. TL:DR):
I don't want to rely on third party libraries, unless it's ABSOLUTELY necessary.
I cannot use CompletableFuture, as I want my minimum API level to be 16.
I don't want to handle this concurrency on the Android side with AsyncTasks, as originally, this is handled in the networking library with a CompletionHandler (Objective-C).
Is there a way to use Future.get() without blocking? (A kind reminder that a while loop checking Future.isDone() also blocks the main thread).

Calling Future.get() is a blocking operation and you cannot change that.
What you want here is to get a callback once the job is done. For this you do not have to use a Future at all. You can always use Executor.execute() with a Runnable doing exactly the same thing as your Callable but instead of returning a value it should call a custom - provided in the method parameter - callback with the value. Basically an equivalent of Consumer interface that was introduced in Java 8.
ExecutorService executorService = Executors.newSingleThreadExecutor();
public void execute(YourRequestObject reqMsg, Consumer<String> consumer) {
executorService.execute(new Runnable() {
#Override
public void run() {
String result = postRequest(reqMsg);
consumer.accept(result);
}
});
}
Also don't create executor each time. Just use one executor for all your operations. Perhaps a cached one instead of singleThread one.
Remember that your callback will be called on the executor thread. If you want to update the UI you need to make a post on UI handler.

You question does not make much sense. On one hand you want to fetch data in separate thread but at the same time get it in another thread without waiting the fetch thread to complete.
What you need to do is wrap fetch and "do whatever with the fetched data" into Runnable and run it in a separate thread.
Make sure to update UI in event dispatch thread in case you need to update it with the fetched data.

Related

CompletableFuture waiting for UI-thread from UI-thread?

Java 8's promise implementation, namely CompletableFuture, provides both thenApply(...) and get() methods.
Where get() waits if necessary for the promise to complete, and then returns its result.
Now assume we use thenApply(...) (or thenApplyAsync(...)) to chain some code to run on UI-thread
(see stackoverflow.com/difference between thenApply and thenApplyAsync).
What is the behaviour if we call get() in the UI-thread as well, like does Java handle this case somehow, or can it result to a so-called dead-lock or infinite-loop?
I previously was using Qt framework, where depending on how we did implement waiter (dispatch-UI-events vs sleep), it was possible to wait for UI-thread from within same UI-thread (for example, the entire view came back to live, and that without returning from my code).
But I am not sure if Java even supports that.
Calling get() blocks the current thread until the result is available. If that's the UI event dispatcher thread then your application's UI becomes unresponsive (blocked).
And unlike Qt, Java does not support manually processing the UI events, meaning once you wait on the UI-thread nothing else can run on UI-thread (until waiter returns).
In addition, don't hack "thenApply(...)" method to run things on UI-thread, as there's a better solution, I mean use the thenApplyAsync(...) version which takes an Executor as parameter. Said Executor is a functional interface with one method, void execute(Runnable command). You can use EventQueue::invokeLater (or its wrapper SwingUtilities.invokeLater) for that. It will then execute the code on the event dispatcher thread (aka UI-thread).

How to globally set thread pool for all CompletableFuture

I am trying to mimic what single threaded async programming in Javascript in Java with the use of async / await library by EA (ea-async). This is mainly because I do not have long-lasting CPU bound computations in my program and I want to code single thread lock free code in Java.
ea-async library heavily relies on the CompletableFuture in Java and underneath Java seems to use ForkJoinPool to run the async callbacks. This puts me into multi threaded environment as my CPU is multi-core. It seems for every CompletableFuture task, I can supply async with my custom thread pool executor. I can supply Executors.newSingleThreadExecutor() for this but I need a way to set this globally so that all CompletableFuture will be using this executor within the single JVM process. How do I do this?
ea-async library heavily relies on the CompletableFuture in Java and
underneath Java seems to use ForkJoinPool to run the async callbacks.
That is the default behavior of CompleteableFuture:
All async methods without an explicit Executor argument are performed
using the ForkJoinPool.commonPool() (unless it does not support a
parallelism level of at least two, in which case, a new Thread is
created to run each task). This may be overridden for non-static
methods in subclasses by defining method defaultExecutor().
That's a defined characteristic of the class, so if you're using class CompleteableFuture, not a subclass, and generating instances without specifying an Executor explicitly, then a ForkJoinPool is what you're going to get.
Of course, if you are in control of the CompletableFutures provided to ea-async then you have the option to provide instances of a subclass that defines defaultExecutor() however you like. Alternatively, you can create your CompleteableFuture objects via the static factory methods that allow you to explicitly specify the Executor to use, such as runAsync​(Runnable, Executor).
But that's probably not what you really want to do.
If you use an executor with only one thread, then your tasks can be executed asynchronously with respect to the thread that submits them, yes, but they will be serialized with respect to each other. You do get only one thread working on them, but it will at any time be working on a specific one, sticking with that one only until it finishes, regardless of the order in which the responses actually arrive. If that's satisfactory, then it's unclear why you want async operations at all.
This puts me into multi threaded environment as my CPU is multi-core.
It puts you in multiple threads regardless of how many cores your CPU has. That's what Executors do, even Executors.newSingleThreadExecutor(). That's the sense of "asynchronous" they provide.
If I understand correctly, you are instead looking to use one thread to multiplex I/O to multiple remote web applications. That is what java.nio.channels.Selector is for, but using that generally requires either managing the I/O operations yourself or using interfaces designed to interoperate with selectors. If you are locked in to third-party interfaces that do not afford use of a Selector, then multithreading and multiprocessing are your only viable alternatives.
In comments you wrote:
I'm starting to think maybe BlockingQueue might do the job in
consolidating all API responses into one queue as tasks where a single
thread will work on them.
Again, I don't think that you want everything that comes with that, and if in fact you do, then I don't see why it wouldn't be even better and easier to work synchronously instead of asynchronously.

CompletableFuture runAsync vs new Thread

Context: I've read this SO thread discussing the differences between CompletableFuture and Thread.
But I'm trying to understand when should I use new Thread() instead of runAsync().
I understand that runAsyn() is more efficient for short/one-time parallel task because my program might avoid the overhead of creating a brand new thread, but should I also consider it for long running operations?
What are the factors that I should be aware before considering to use one over the other?
Thanks everyone.
The difference between using the low-level concurrency APIs (such as Thread) and others is not just about the kind of work that you want to get done, it's also about the programming model and also how easy they make it to configure the environment in which the task runs.
In general, it is advisable to use higher-level APIs, such as CompletableFuture instead of directly using Threads.
I understand that runAsyn() is more efficient for short/one-time parallel task
Well, maybe, assuming you call runAsync, counting on it to use the fork-join pool. The runAsync method is overloaded with a method that allows one to specify the java.util.concurrent.Executor with which the asynchronous task is executed.
Using an ExecutorService for more control over the thread pool and using CompletableFuture.runAsync or CompletableFuture.supplyAsync with a specified executor service (or not) are both generally preferred to creating and running a Thread object directly.
There's nothing particularly for or against using the CompletableFuture API for long-running tasks. But the choice one makes to use Threads has other implications as well, among which:
The CompletableFuture gives a better API for programming reactively, without forcing us to write explicit synchronization code. (we don't get this when using threads directly)
The Future interface (which is implemented by CompletableFuture) gives other additional, obvious advantages.
So, in short: you can (and probably should, if the alternative being considered is the Thread API) use the CompletableFuture API for your long-running tasks. To better control thread pools, you can combine it with executor services.
The main difference is CompletableFuture run your task by default on the ForkJoinPool.commonPool. But if you create your own thread and start it will execute as a single thread, not on a Thread pool. Also if you want to execute some task in a sequence but asynchronously. Then you can do like below.
CompletableFuture.runAsync(() -> {
System.out.println("On first task");
System.out.println("Thread : " + Thread.currentThread());
}).thenRun(() -> {
System.out.println("On second task");
});
Output:
On first task
Thread : Thread[ForkJoinPool.commonPool-worker-1,5,main]
On second task
If you run the above code you can see that which pool CompletableFuture is using.
Note: Threads is Daemon in ForkJoinPool.commonPool.

Java Async is blocking?

After doing lots of searching on Java, I really am very confused over the following questions:
Why would I choose an asynchronous method over a multi-threaded method?
Java futures are supposed to be non-blocking. What does non-blocking mean? Why call it non-blocking when the method to extract information from a Future--i.e., get()--is blocking and will simply halt the entire thread till the method is done processing? Perhaps a callback method that rings the church bell of completion when processing is complete?
How do I make a method async? What is the method signature?
public List<T> databaseQuery(String Query, String[] args){
String preparedQuery = QueryBaker(Query, args);
List<int> listOfNumbers = DB_Exec(preparedQuery); // time taking task
return listOfNumbers;
}
How would this fictional method become a non blocking method? Or if you want please provide a simple synchronous method and an asynchronous method version of it.
Why would I choose an asynchronous method over a multi-threaded method?
Asynchronous methods allow you to reduce the number of threads. Instead of tying up a thread in a blocking call, you can issue an asynchronous call and then be notified later when it completes. This frees up the thread to do other processing in the meantime.
It can be more convoluted to write asynchronous code, but the benefit is improved performance and memory utilization.
Java futures are supposed to be non-blocking. What does non-blocking mean? Why call it non-blocking when the method to extract information from a Future--i.e., get()--is blocking and will simply halt the entire thread till the method is done processing ? Perhaps a callback method that rings the church bell of completion when processing is complete?
Check out CompletableFuture, which was added in Java 8. It is a much more useful interface than Future. For one, it lets you chain all kinds of callbacks and transformations to futures. You can set up code that will run once the future completes. This is much better than blocking in a get() call, as you surmise.
For instance, given asynchronous read and write methods like so:
CompletableFuture<ByteBuffer> read();
CompletableFuture<Integer> write(ByteBuffer bytes);
You could read from a file and write to a socket like so:
file.read()
.thenCompose(bytes -> socket.write(bytes))
.thenAccept(count -> log.write("Wrote {} bytes to socket.", count)
.exceptionally(exception -> {
log.error("Input/output error.", exception);
return null;
});
How do I make a method async? What is the method signature?
You would have it return a future.
public CompletableFuture<List<T>> databaseQuery(String Query, String[] args);
It's then the responsibility of the method to perform the work in some other thread and avoid blocking the current thread. Sometimes you will have worker threads ready to go. If not, you could use the ForkJoinPool, which makes background processing super easy.
public CompletableFuture<List<T>> databaseQuery(String query, String[] args) {
CompletableFuture<List<T>> future = new CompletableFuture<>();
Executor executor = ForkJoinPool.commonPool();
executor.execute(() -> {
String preparedQuery = QueryBaker(Query, args);
List<T> list = DB_Exec(preparedQuery); // time taking task
future.complete(list);
});
}
why would I choose a Asynchronous method over a multi-threaded method
They sound like the same thing to me except asynchronous sounds like it will use one thread in the back ground.
Java futures is supposed to be non blocking ?
Non- blocking operations often use a Future, but the object itself is blocking, though only when you wait on it.
What does Non blocking mean?
The current thread doesn't wait/block.
Why call it non blocking when the method to extract information from a Future < some-object > i.e. get() is blocking
You called it non-blocking. Starting the operation in the background is non-blocking, but if you need the results, blocking is the easiest way to get this result.
and will simply halt the entire thread till the method is done processing ?
Correct, it will do that.
Perhaps a callback method that rings the church bell of completion when processing is complete ?
You can use a CompletedFuture, or you can just add to the task anything you want to do at the end. You only need to block on things which have to be done in the current thread.
You need to return a Future, and do something else while you wait, otherwise there is no point using a non-blocking operation, you may as well execute it in the current thread as it's simpler and more efficient.
You have the synchronous version already, the asynchronous version would look like
public Future<List<T>> databaseQuery(String Query, String[] args) {
return executor.submit(() -> {
String preparedQuery = QueryBaker(Query, args);
List<int> listOfNumbers = DB_Exec(preparedQuery); // time taking task
return listOfNumbers;
});
}
I'm not a guru on multithreading but I'm gonna try to answer these questions for my sake as well
why would I choose a Asynchronous method over a multi-threaded method ? (My problem: I believe I read too much and now I am myself confused)`
Multi-threading is working with multiple threads, there isn't much else to it. One interesting concept is that multiple threads cannot work in a truly parallel fashion and thus divides each thread into small bits to give the illusion of working in parallel.
1
One example where multithreading would be useful is in real-time multiplayer games, where each thread corresponds to each user. User A would use thread A and User B would use thread B. Each thread could track each user's activity and data could be shared between each thread.
2
Another example would be waiting for a long http call. Say you're designing a mobile app and the user clicks on download for a file of 5 gigabytes. If you don't use multithreading, the user would be stuck on that page without being able to perform any action until the http call completes.
It's important to note that as a developer multithreading is only a way of designing code. It adds complexity and doesn't always have to be done.
Now for Async vs Sync, Blocking vs Non-blocking
These are some definitions I found from http://doc.akka.io/docs/akka/2.4.2/general/terminology.html
Asynchronous vs. Synchronous
A method call is considered synchronous if the caller cannot make progress until the method returns a value or throws an exception. On the other hand, an asynchronous call allows the caller to progress after a finite number of steps, and the completion of the method may be signalled via some additional mechanism (it might be a registered callback, a Future, or a message).
A synchronous API may use blocking to implement synchrony, but this is not a necessity. A very CPU intensive task might give a similar behavior as blocking. In general, it is preferred to use asynchronous APIs, as they guarantee that the system is able to progress. Actors are asynchronous by nature: an actor can progress after a message send without waiting for the actual delivery to happen.
Non-blocking vs. Blocking
We talk about blocking if the delay of one thread can indefinitely delay some of the other threads. A good example is a resource which can be used exclusively by one thread using mutual exclusion. If a thread holds on to the resource indefinitely (for example accidentally running an infinite loop) other threads waiting on the resource can not progress. In contrast, non-blocking means that no thread is able to indefinitely delay others.
Non-blocking operations are preferred to blocking ones, as the overall progress of the system is not trivially guaranteed when it contains blocking operations.
I find that async vs sync refers more to the intent of the call whereas blocking vs non-blocking refers to the result of the call. However, it wouldn't be wrong to say usually asynchronous goes with non-blocking and synchronous goes with blocking.
2> Java futures is supposed to be non blocking ? What does Non blocking mean? Why call it non blocking when the method to extract information from a Future < some-object > i.e. get() is blocking and will simply halt the entire thread till the method is done processing ? Perhaps a callback method that rings the church bell of completion when processing is complete ?
Non-blocking do not block the thread that calls the method.
Futures were introduced in Java to represent the result of a call, although it may have not been complete. Going back to the http file example, Say you call a method like the following
Future<BigData> future = server.getBigFile(); // getBigFile would be an asynchronous method
System.out.println("This line prints immediately");
The method getBigFile would return immediately and proceed to the next line of code. You would later be able to retrieve the contents of the future (or be notified that the contents are ready). Libraries/Frameworks like Netty, AKKA, Play use Futures extensively.
How do I make a method Async? What is the method signature?
I would say it depends on what you want to do.
If you want to quickly build something, you would use high level functions like Futures, Actor models, etc. something which enables you to efficiently program in a multithreaded environment without making too many mistakes.
On the other hand if you just want to learn, I would say it's better to start with low level multithreading programming with mutexes, semaphores, etc.
Examples of codes like these are numerous in google if you just search java asynchronous example with any of the keywords I have written.
Let me know if you have any other questions!

Concurrency through ExecutorService in Java

I'm using below concurrency feature of Java 1.6 to execute some task offline. When the user is created through registration, I need to perform some inhouse logging task & I don't want to block the user, so I've been using the below code
java.util.concurrent.ExecutorService myservice = Executors.newSingleThreadExecutor();
myservice.execute(new myTask(user));
Here, I'm having an inner class myTask which implements Runnable & in Run method, I'm doing offline activity (thus making it as a non-blocking call).
Now, once the user logs in to website, there are certain actions (buttons on web pages) clicking on which I need to do similar offline activities & I don't want to make the call as a blocking call. I've 4 actions on this page on which I need to perform offline tasks.
Is it ok to use the similar above code with 4 different inner classes & perform offline activity within them?? If not, whats the alternative?
Thanks!
You can use Executors if you are not expecting high level of concurrent requests. Use Thread pool in this case.
If yours is a highly-concurrent app and you should guarantee the processing of the action (even in case of jvm crash) and you want the actions to be transactional then messaging (JMS) might be the solution.
I've successfully used Executors with pools successfully earlier in a web-application. It is however not recommended to create threads in a web-app and not allowed in an EJB as the threads are not managed by the container.
Example
static final int POOL_SIZE=10;
ExecutorService pool = Executors.newFixedThreadPool(POOL_SIZE);
You can also read this nice article: Java Concurrency
In additions to your Thread Pool you should use a thread safe queue for allowing more work than threads available.

Categories