blockingForEach(), why apply function to blocked observables

Question

I'm having trouble understanding the point of a blocking Observable, specifically blockingForEach()

What is the point in applying a function to an Observable that we will never see?? Below, I'm attempting to have my console output in the following order

this is the integer multiplied by two:2
this is the integer multiplied by two:4
this is the integer multiplied by two:6
Statement comes after multiplication

My current method prints the statement before the multiplication

 fun rxTest(){
    val observer1  = Observable.just(1,2,3).observeOn(AndroidSchedulers.mainThread())

    val observer2 = observer1.map { response -> response * 2 }


    observer2
            .observeOn(AndroidSchedulers.mainThread())
            .subscribeOn(AndroidSchedulers.mainThread())
            .subscribe{ it -> System.out.println("this is the integer multiplie by two:" + it) }

    System.out.println("Statement comes after multiplication ")
}

Now I have my changed my method to include blockingForEach()

 fun rxTest(){
    val observer1  = Observable.just(1,2,3).observeOn(AndroidSchedulers.mainThread())

    val observer2 = observer1.map { response -> response * 2 }


    observer2
            .observeOn(AndroidSchedulers.mainThread())
            .subscribeOn(AndroidSchedulers.mainThread())
            .blockingForEach { it -> System.out.println("this is the integer multiplie by two:" + it) }

    System.out.println("Statement comes after multiplication ")
}

1.)What happens to the transformed observables once no longer blocking? Wasnt that just unnecessary work since we never see those Observables??

2.)Why is my System.out("Statement...) appear before my observables when I'm subscribing?? Its like observable2 skips its blocking method, makes the System.out call and then resumes its subscription

Answer 1

It's not clear what you mean by your statement that you will "never see" values emitted by an observer chain. Each value that is emitted in the observer chain is seen by observers downstream from the point where they are emitted. At the point where you subscribe to the observer chain is the usual place where you perform a side effect, such as printing a value or storing it into a variable. Thus, the values are always seen.

In your examples, you are getting confused by how the schedulers work. When you use the observeOn() or subscribeOn() operators, you are telling the observer chain to emit values after the value is move on to a different thread. When you move data between threads, the destination thread has to be able to process the data. If your main code is running on the same thread, you can lock yourself out or you will re-order operations.

Normally, the use of blocking operations is strongly discouraged. Blocking operations can often be used when testing, because you have full control of the consequences. There are a couple of other situations where blocking may make sense. An example would be an application that requires access to a database or other resource; the application has no purpose without that resource, so it blocks until it becomes available or a timeout occurs, kicking it out.