Develop Reference

Correctly handling backpressure from an async call

I have some code that looks roughly like this:
Completable handle(Observable<Object> inbound) {
return inbound.buffer(1, TimeUnit.Second, 250)
.filter(l -> !l.isEmpty())
.flatMapToCompletable(this::sendToClient);
}
Completable sendToClient(List<Object> list) {
// call IO asynchronously
}
inbound is a cold observable that is producing in a standard while loop (but on another Thread!). While not disposed, fetch some data and call onNext().
The issue I face is that sendToClient is too "slow", it can't keep up with the speed at which inbound is producing data. It's an async operation that is essentially queuing the calls to the client in memory somewhere (don't have access to this code) and eventually filling the heap.
I need a way to figure out a way to get inbound to stop producing when these calls start to stack up. Is there a way to achieve this using inbuild operators?

I would probably suggest creating a thread pool to handle the sendToClient operations. This can support having a queue of requests waiting to be handled, but you can also specify behavior if the queue is full (ie, too much back pressure).
Take a look at java.util.concurrent.ThreadPoolExecutor

Is it possible for this Android LiveData/Threading code to give some kind of concurrency issue or unexpected result?

I have some similar code throughout my project that is inside of my ViewModels which subscribes to an RxJava observable that is subscribedOn Schedulers.computation(). I have a MutableLiveData<Integer> isLoadedLiveData object that posts an updated int flag that will be observed in my activity.
Basically, in this ViewModel, if 3 subscriptions finish, then the isLoadedLiveData will be equal to 3 because each subscriptions adds to increments the int flag value of isLoadedLiveData. And in my LiveData observer of isLoadedLiveData in my activity, I then set up the views of that Activity once the int value is equal 3. So it lets me know that the ViewModel data is ready to go and each needed piece of data can be returned from each repsective getter. I do this so I don't need a bunch of LiveData objects in my Activity and can instead just have one flag that tells me when all my separate data is loaded.
Here is a section of the code in my ViewModel:
Disposable disposable1 = this.thingRepository.getThingSingle()
.observeOn(Schedulers.computation())
.subscribe(thing -> {
name = thing.getName();
abbrev = thing.getAbbrev();
stuff = thing.getStuff();
loaded++;
isLoadedLiveData.postValue(loaded);
});
Now I'll preface this by saying I am not well versed in java/android concurrency, so I am not exactly sure, but I wouldn't think this code could give me some kind of problem. But I am not 100% sure. Could this possibly be problematic in certain situations, or will the sequence of code and threading not be an issue?
The data like name, abbrev, and stuff which are fields of my ViewModel are all returned to my Activity eventually (just through simple getters, no observers). Will these pieces of data always be correctly updated and safe to access from my Activity on the MainThread because the int flag being posted to isLoadedLiveData always occurs after the data is updated on the background threads. I am not completely sure because these values are being updated on a background thread and then the main thread accesses it. I don't know enough about concurrency.
This doesn't have much to do with RxJava but that is how I handle my threading in this case. It is more to do with Java Threading/Android Threading/LiveData in general. I am not completely sure how LiveData .postValue works, but I would assume it gets put in the main thread's Looper to execute my LiveData Observer callback with the posted value passed in. Will this no matter what always occur so that the values set above the isLoadedLiveData.postValue(loaded) are safe to access and correctly updated?
I appreciate any responses! Thanks.
Edit: Here is new code:
Disposable disposable1 = this.thingRepository.getThingSingle()
.subscribeOn(Schedulers.computation())
.doOnSuccess(thing -> {
name = thing.getName();
abbrev = thing.getAbbrev();
heavyOperationResult = heavyOpperation(thing);
stuff = thing.getStuff();
})
.observeOn(AndroidSchedulers.mainThread())
.subscribe(thing -> {
loaded++;
isLoadedLiveData.setValue(loaded);
});
I added .subscribeOn(Schedulers.computation()) even though my repository returns a Single that is already subscribed on Schedulers.computation() just to express what thread it was subscribed on for the purposes of this example. I also added the heavyOperation(thing) just to show that I need it in the background because I do some computation that could take too long for the main UI thread.

I disagree with that code snippet, you are mis-using Rx in my opinion.
Two things:
doOnSuccess is meant to be used for side-effects, not for doing heavy computations.
Do NOT take the state out of the Rx stream, pass it downstream instead. This statement name = thing.getName(); and others like that inside doOnSuccess are really dangerous because you could have several streams modifying the same state in different threads.
What you want is to actually pass the state downstream and eventually publish it in LiveData, then you observe it as it changes.
Disposable disposable = thingRepository.getThingSingle()
.subscribeOn(Schedulers.io())
.flatMap(thing ->
Single.fromCallable(() -> heavyOperation(thing))
.map(heavyOperationResult -> new Pair<>(thing, heavyOperationResult))
.subscribeOn(Schedulers.computation()))
.observeOn(AndroidSchedulers.mainThread())
.subscribe(pair -> {
Thing thing = pair.getValue0();
HeavyOperationResult heavyOperationResult = pair.getValue1();
thingLiveData.setValue(thing);
heavyOperationLiveData.setValue(heavyOperationResult);
});

Output result of heavy calculation in Vert.x with back-pressure

The application in question handles requests from clients which then requires a lot of calculation on the server side. This calculation is done piece-by-piece, so if the client is slow to read, this calculation should not progress (the calculation should respond to back-pressure).
The calculation is now represented as a Supplier<Buffer>, in which the get() call might take a long time and needs to be called multiple times until it responds with null (no more data). The get() should be called in a separate thread-pool (which is shared with other requests), and should only be called if the client is really able to accept the data.
My current code is:
ReadStream<Buffer> readStream = new MyComplicatedReadStream(supplier, executor)
.exceptionHandler(request::fail)
.endHandler(x -> request.response().end());
Pump.pump(readStream, request.response())).start();
I've made a custom implementation of ReadStream to do this, which sort-of works, but is long, clunky and has synchronization issues.
Instead of fixing that, I wonder if there is a idiomatic way in vert.x / rx to implement / instantiate a MyComplicatedReadStream. So, for a Supplier<Buffer> and an ExecutorService get a ReadStream<Buffer> which executes get() with the given executor and doesn't generate if it is paused.

I have near 0 experience with vert.x but I do have some experience with rxjava. So there might be a better way to do this but from rxjava perspective you can make use of generate method to create 'cold' flowables which only generate items on demand. I believe in this case when the stream is paused, no additional calls to supplier.get() will be made as there is no 'demand'
using kotlin syntax here but I think you can derive the java version easily.
Flowable.generate<Buffer> { emitter ->
val nextValue = supplier.get()
if (nextValue == null) {
emitter.onComplete()
} else {
emitter.onNext(nextValue)
}
}.subscribeOn(Schedulers.from(executor)) // this will make the above callback run in the given executor
Since it seems that the supplier is holding some state, you may in some cases want to generate a 'new supplier' for each consumer, in which case you can use the overload of the generate method that allows specifying another callback to get an instance of the state (supplier in your case). http://reactivex.io/RxJava/2.x/javadoc/io/reactivex/Flowable.html#generate-java.util.concurrent.Callable-io.reactivex.functions.BiConsumer-
Looks like then you can convert the flowable to a read stream:
ReadStream<Buffer> readStream = FlowableHelper.toReadStream(observable);
based on the docs here: https://vertx.tk/docs/vertx-rx/java2/#_read_stream_support

What's the point of using Future without multithreading?

I've inherited some code and there is nobody of the original developers left. The code uses heavily CompletableFuture, and it's the first time I use it, so I'm still trying to wrap my head around it. As I understand it, a (Completable)Future is typically used with some multithreading mechanism that will allow us to do some other thing while a time consuming task is executing, and then simply fetch its result via the Future. As in the javadoc:
interface ArchiveSearcher { String search(String target); }
class App {
ExecutorService executor = ...
ArchiveSearcher searcher = ...
void showSearch(final String target) throws InterruptedException {
Future<String> future = executor.submit(new Callable<String>() {
public String call() {
return searcher.search(target);
}});
displayOtherThings(); // do other things while searching
try {
displayText(future.get()); // use future
} catch (ExecutionException ex) { cleanup(); return; }
}
}
However, in this application that I've inherited, the following pattern that doesn't use any multithreading appears a bunch of times:
public Object serve(Object input) throws ExecutionException, InterruptedException {
CompletableFuture<Object> result = delegate1(input);
return result.get();
}
private CompletableFuture<Object> delegate1(Object input) {
// Do things
return delegate2(input);
}
private CompletableFuture<Object> delegate2(Object input) {
return CompletableFuture.completedFuture(new Object());
}
To me, this is equivalent to:
public Object serve(Object input) {
Object result = delegate1(input);
return result;
}
private Object delegate1(Object input) {
// Do things
return delegate2(input);
}
private Object delegate2(Object input) {
return new Object();
}
Of course the code is much more complex, and returns exceptionallyCompletedFuture in case of error, but there are is Callable, no Runnable, no Executor, no supplyAsync() no sign of multithreading. What am I missing? What's the point of using a Future in a singled-threaded context?

Futures are critical for situations where there is asynchronous programming. One of the biggest advantages of asynchronous programming is it allows you to write very efficient code with a single thread.
Furthermore, futures tend to be an all-or-nothing proposition. If you want to write asynchronous code you have to do so from top to bottom, even if not every method does something asynchronous.
For example, consider you want to write a single threaded HTTP server like twisted or express. The top level of your server (very liberal pseudocode here) might look something like:
while (true) {
if (serverSocket.ready()) {
connection = serverSocket.accept();
futures.add(server.serve(connection));
}
for (Future future : futures) {
if (future.isDone()) {
Object result = future.get();
sendResult(result);
}
}
//Some kind of select-style wait here
}
There is only one thread but any time an operation happens that would normally require a wait (reading from database, file, reading in the request, etc.) it uses futures and doesn't block the one thread so you have a highly performant single threaded HTTP server.
Now, imagine what would happen if the highest level of your application was like the above and at some point some request at a very low level had to read something from a file. That file read would generate a future. If all of your middle layers in between didn't handle futures then you would have to block and it would defeat the purpose. This is why I say futures tend to be all-or-nothing.
So my guess is either:
Your friend does something asynchronous currently and you haven't caught it yet (does he ever read from a file or database or anything? If so, is he blocking?).
He was planning on someday doing something asynchronous and wanted to plan for it.
He spent a lot of time in other asynchronous frameworks and grew to like the style even if he isn't using it correctly.

Yes, for now there is no multithreading used in that code. Looks like there was an intention to write single-threaded code in such a way that if developer later decides to use multithreading then only
delegate2()
method should be modified.

ExecutorService implementations typically manage threads. I've used the ThreadPoolExecutor, which does exactly that. You commented out which ExecutorService your code uses.

The main point of asynchronous code is to defer the continuation code.
The most common scenario is I/O, where instead of waiting for an operation to finish, you say "do your thing and notify me when you're finished", or more commonly, "do your thing and do this when you're finished".
This doesn't imply threads at all. Reading from any device, be it a network card or a hard drive, usually has some sort of signal or interrupt sent from the device to the CPU. You could use the CPU in the meantime. The "notify me" is more common in lower-level code, where you implement a dispatching loop or scheduler; the "do this" is more common in higher-level code, where you use an established library or framework that dispatches and/or schedules for you.
Less common scenarios include deferring execution without blocking a thread (think of a timer versus Thread.sleep()) and splitting work. Actually, splitting work is very common with multiple threads, where you can improve performance with a bit of overhead, but not so much with a single thread, where the overhead is just, well, overhead.
The code you provide as an example that just builds completed CompletableFutures, whether successfully or exceptionally, is a part of the overhead of asynchronous code that isn't really asynchronous. That is, you must still follow a defined async style, which in this case requires a small amount of memory allocation for results, even if you can provide results immediately.
This may become noticeable on thousands of calls per second, or hundreds of calls per second per thread with dozens of threads.
Sometimes, you can optimize by having predefined completed futures for e.g. null, 0, 1, -1, an empty array/list/stream, or any other very common or even fixed result you may have specifically in your domain. A similar approach is to cache a wrapping future, not just the result, while the result remains the same. But I suggest you first profile before going this way, you may end up optimizing prematurely something that most probably is not a bottleneck.

Difference between Futures(Guava)/CompletableFuture and Observable(RxJava) [duplicate]

I would like to know the difference between
CompletableFuture,Future and Observable RxJava.
What I know is all are asynchronous but
Future.get() blocks the thread
CompletableFuture gives the callback methods
RxJava Observable --- similar to CompletableFuture with other benefits(not sure)
For example: if client needs to make multiple service calls and when we use Futures (Java) Future.get() will be executed sequentially...would like to know how its better in RxJava..
And the documentation http://reactivex.io/intro.html says
It is difficult to use Futures to optimally compose conditional asynchronous execution flows (or impossible, since latencies of each request vary at runtime). This can be done, of course, but it quickly becomes complicated (and thus error-prone) or it prematurely blocks on Future.get(), which eliminates the benefit of asynchronous execution.
Really interested to know how RxJava solves this problem. I found it difficult to understand from the documentation.

Futures
Futures were introduced in Java 5 (2004). They're basically placeholders for a result of an operation that hasn't finished yet. Once the operation finishes, the Future will contain that result. For example, an operation can be a Runnable or Callable instance that is submitted to an ExecutorService. The submitter of the operation can use the Future object to check whether the operation isDone(), or wait for it to finish using the blocking get() method.
Example:
/**
* A task that sleeps for a second, then returns 1
**/
public static class MyCallable implements Callable<Integer> {
#Override
public Integer call() throws Exception {
Thread.sleep(1000);
return 1;
}
}
public static void main(String[] args) throws Exception{
ExecutorService exec = Executors.newSingleThreadExecutor();
Future<Integer> f = exec.submit(new MyCallable());
System.out.println(f.isDone()); //False
System.out.println(f.get()); //Waits until the task is done, then prints 1
}
CompletableFutures
CompletableFutures were introduced in Java 8 (2014). They are in fact an evolution of regular Futures, inspired by Google's Listenable Futures, part of the Guava library. They are Futures that also allow you to string tasks together in a chain. You can use them to tell some worker thread to "go do some task X, and when you're done, go do this other thing using the result of X". Using CompletableFutures, you can do something with the result of the operation without actually blocking a thread to wait for the result. Here's a simple example:
/**
* A supplier that sleeps for a second, and then returns one
**/
public static class MySupplier implements Supplier<Integer> {
#Override
public Integer get() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
//Do nothing
}
return 1;
}
}
/**
* A (pure) function that adds one to a given Integer
**/
public static class PlusOne implements Function<Integer, Integer> {
#Override
public Integer apply(Integer x) {
return x + 1;
}
}
public static void main(String[] args) throws Exception {
ExecutorService exec = Executors.newSingleThreadExecutor();
CompletableFuture<Integer> f = CompletableFuture.supplyAsync(new MySupplier(), exec);
System.out.println(f.isDone()); // False
CompletableFuture<Integer> f2 = f.thenApply(new PlusOne());
System.out.println(f2.get()); // Waits until the "calculation" is done, then prints 2
}
RxJava
RxJava is whole library for reactive programming created at Netflix. At a glance, it will appear to be similar to Java 8's streams. It is, except it's much more powerful.
Similarly to Futures, RxJava can be used to string together a bunch of synchronous or asynchronous actions to create a processing pipeline. Unlike Futures, which are single-use, RxJava works on streams of zero or more items. Including never-ending streams with an infinite number of items. It's also much more flexible and powerful thanks to an unbelievably rich set of operators.
Unlike Java 8's streams, RxJava also has a backpressure mechanism, which allows it to handle cases in which different parts of your processing pipeline operate in different threads, at different rates.
The downside of RxJava is that despite the solid documentation, it is a challenging library to learn due to the paradigm shift involved. Rx code can also be a nightmare to debug, especially if multiple threads are involved, and even worse - if backpressure is needed.
If you want to get into it, there's a whole page of various tutorials on the official website, plus the official documentation and Javadoc. You can also take a look at some of the videos such as this one which gives a brief intro into Rx and also talks about the differences between Rx and Futures.
Bonus: Java 9 Reactive Streams
Java 9's Reactive Streams aka Flow API are a set of Interfaces implemented by various reactive streams libraries such as RxJava 2, Akka Streams, and Vertx. They allow these reactive libraries to interconnect, while preserving the all important back-pressure.

I have been working with Rx Java since 0.9, now at 1.3.2 and soon migrating to 2.x I use this in a private project where I already work on for 8 years.
I wouldn't program without this library at all anymore. In the beginning I was skeptic but it is a complete other state of mind you need to create. Quiete difficult in the beginning. I sometimes was looking at the marbles for hours.. lol
It is just a matter of practice and really getting to know the flow (aka contract of observables and observer), once you get there, you'll hate to do it otherwise.
For me there is not really a downside on that library.
Use case:
I have a monitor view that contains 9 gauges (cpu, mem, network, etc...). When starting up the view, the view subscribes itselfs to a system monitor class that returns an observable (interval) that contains all the data for the 9 meters.
It will push each second a new result to the view (so not polling !!!).
That observable uses a flatmap to simultaneously (async!) fetch data from 9 different sources and zips the result into a new model your view will get on the onNext().
How the hell you gonna do that with futures, completables etc ... Good luck ! :)
Rx Java solves many issues in programming for me and makes in a way a lot easier...
Advantages:
Statelss !!! (important thing to mention, most important maybe)
Thread management out of the box
Build sequences that have their own lifecycle
Everything are observables so chaining is easy
Less code to write
Single jar on classpath (very lightweight)
Highly concurrent
No callback hell anymore
Subscriber based (tight contract between consumer and producer)
Backpressure strategies (circuit breaker a like)
Splendid error handling and recovering
Very nice documentation (marbles <3)
Complete control
Many more ...
Disadvantages:
- Hard to test

Java's Future is a placeholder to hold something that will be completed in the future with a blocking API. You'll have to use its' isDone() method to poll it periodically to check if that task is finished. Certainly you can implement your own asynchronous code to manage the polling logic. However, it incurs more boilerplate code and debug overhead.
Java's CompletableFuture is innovated by Scala's Future. It carries an internal callback method. Once it is finished, the callback method will be triggered and tell the thread that the downstream operation should be executed. That's why it has thenApply method to do further operation on the object wrapped in the CompletableFuture.
RxJava's Observable is an enhanced version of CompletableFuture. It allows you to handle the backpressure. In the thenApply method (and even with its brothers thenApplyAsync) we mentioned above, this situation might happen: the downstream method wants to call an external service that might become unavailable sometimes. In this case, the CompleteableFuture will fail completely and you will have to handle the error by yourself. However, Observable allows you to handle the backpressure and continue the execution once the external service to become available.
In addition, there is a similar interface of Observable: Flowable. They are designed for different purposes. Usually Flowable is dedicated to handle the cold and non-timed operations, while Observable is dedicated to handle the executions requiring instant responses. See the official documents here: https://github.com/ReactiveX/RxJava#backpressure

All three interfaces serve to transfer values from producer to consumer. Consumers can be of 2 kinds:
synchronous: consumer makes blocking call which returns when the value is ready
asynchronous: when the value is ready, a callback method of the consumer is called
Also, communication interfaces differ in other ways:
able to transfer single value of multiple values
if multiple values, backpressure can be supported or not
As a result:
Future transferes single value using synchronous interface
CompletableFuture transferes single value using both synchronous and asynchronous interfaces
Rx transferes multiple values using asynchronous interface with backpressure
Also, all these communication facilities support transferring exceptions. This is not always the case. For example, BlockingQueue does not.

The main advantage of CompletableFuture over normal Future is that CompletableFuture takes advantage of the extremely powerful stream API and gives you callback handlers to chain your tasks, which is absolutely absent if you use normal Future. That along with providing asynchronous architecture, CompletableFuture is the way to go for handling computation heavy map-reduce tasks, without worrying much about application performance.