# When multiple subscribeOn()s do have effect

DevFeed: [When multiple subscribeOn()s do have effect](<https://devfeed.tech/articles/when-multiple-subscribeon-s-do-have-effect-24817.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2017/11/when-multiple-subscribeons-do-have.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2017-11-29T12:33:00Z

Content type: tutorial

Language: en

Sources: [Akarnokd - Advanced RxJava](<https://devfeed.tech/sources/akarnokd-advanced-rxjava.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>)

Tags: [collect](<https://devfeed.tech/tags/collect.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [filter](<https://devfeed.tech/tags/filter.md>), [flowable](<https://devfeed.tech/tags/flowable.md>), [io](<https://devfeed.tech/tags/io.md>), [main-thread](<https://devfeed.tech/tags/main-thread.md>), [map](<https://devfeed.tech/tags/map.md>), [scheduler](<https://devfeed.tech/tags/scheduler.md>), [subscribeon](<https://devfeed.tech/tags/subscribeon.md>), [take](<https://devfeed.tech/tags/take.md>), [thread](<https://devfeed.tech/tags/thread.md>), [tutorials](<https://devfeed.tech/tags/tutorials.md>)

## AI overview

This article explains why multiple subscribeOn() operators can sometimes have observable effects. It distinguishes source operators that perform subscription side effects from instance operators that mainly subscribe upstream, and shows how different schedulers can determine the threads where those effects occur.

## Source excerpt

Introduction In many tutorials and explanations, it has been said that having multiple subscribeOn()s has no effect and only the one closest to the source wins. I often tell this with the wording "no practical effect". However, it is possible to demonstrate the effects of multiple subscibeOn()s that have some actual effects. What is subscribeOn again? The most precise definition of this operator I can formulate is as follows: subscribeOn changes where (on what thread) the (side) effects of calling subscribe() on the parent/upstream Observable (Flowable, Single, etc.) happen. So what are these subscription (side) effects look like in code? Observable.create(emitter -> { for (int i = 0; i < 10; i++) { emitter.onNext(i + ": " + Thread.currentThread().getName()); } emitter.onComplete(); }) .subscribeOn(Schedulers.io()) .blockingSubscribe(System.out::println); // Prints: // ------- // 0: RxCachedThreadScheduler-1 // 1: RxCachedThreadScheduler-1 // 2: RxCachedThreadScheduler-1 // 3: RxCachedThreadScheduler-1 // 4: RxCachedThreadScheduler-1 // 5: RxCachedThreadScheduler-1 // 6: RxCachedThreadScheduler-1 // 7: RxCachedThreadScheduler-1 // 8: RxCachedThreadScheduler-1 // 9: RxCachedThreadScheduler-1 In this example, the effect of subscribing is that the body of the ObservableOnSubscribe starts running on the thread provided via the io() Scheduler. Applying yet another subscribeOn after the first one won't change what is printed to the console. Most source-like operators, such as create(), fromCallable(), fromIterable(), do have subscription side-effects as they often start emitting event(s) immediately. Most instance operators, such as map(), filter(), take(), don't have subscription side-effects on their own and just subscribe() to their upstream. Instance operators with subscription side-effects However, there are a couple of instance operators that do have subscription side-effects. Specifically, any operator that offers a way to specify a per subscriber initial state via