# SubscribeOn and ObserveOn

DevFeed: [SubscribeOn and ObserveOn](<https://devfeed.tech/articles/subscribeon-and-observeon-24799.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2016/03/subscribeon-and-observeon.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2016-03-31T12:55:00Z

Content type: tutorial

Language: en

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

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [reactive](<https://devfeed.tech/topics/reactive.md>), [User Experience](<https://devfeed.tech/topics/user-experience.md>), [Android](<https://devfeed.tech/topics/android.md>), [GUI](<https://devfeed.tech/topics/gui.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [blocking](<https://devfeed.tech/tags/blocking.md>), [cancellation](<https://devfeed.tech/tags/cancellation.md>), [executorservice](<https://devfeed.tech/tags/executorservice.md>), [main-thread](<https://devfeed.tech/tags/main-thread.md>), [observeon](<https://devfeed.tech/tags/observeon.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [subscribeon](<https://devfeed.tech/tags/subscribeon.md>), [thread](<https://devfeed.tech/tags/thread.md>)

## AI overview

A tutorial explaining why RxJava's subscribeOn and observeOn operators are often confused. It distinguishes their effects by tracing subscription and method-call flow, and discusses moving subscription side effects such as network, database, or blocking work away from the current thread.

## Source excerpt

Introduction One of the most confused operator pair of the reactive ecosystem is the subscribeOn and observeOn operators. The source of confusion may be rooted in a few causes: they sound alike, they sometimes show similar behavior when looked at from downstream and they are duals in some sense. It appears the name-confusion isn't local to RxJava. Project Reactor faces a similar issue with their publishOn and dispatchOn operators. Apparently, it doesn't matter what they are called and people will confuse them anyhow. When I started learning about Rx.NET back in 2010, I never experienced this confusion; subscribeOn affects subscribe() and observeOn affects onXXX(). (Remark: I've searched Channel 9 for the early videos but couldn't really find the talk where they build up these operators just like I'm about to do. The closest thing was this.) My "thesis" is that the confusion may be resolved by walking through how one can implement these operators and thus showing the internal method-call flow. SubscribeOn The purpose of subscribeOn() is to make sure side-effects from calling subscribe() happens on some other thread. However, almost no standard RxJava source does side-effects on its own; you can have side-effects with custom Observables, wrapped subscription-actions via create() or as of lately, the with the SyncOnSubscribe and fromCallable() APIs. Why would one move the side-effects? The main use cases are doing network calls or database access on the current thread or anything that involves blocking wait. Holding off a Tomcat worker thread hasn't been much of a programming problem (that doesn't mean we can't improve the stack with reactive) but holding off the Event Dispatch Thread in a Swing application or the Main thread in an Android application has adverse effect on the user experience. (Sidenote: it's a funny thing that blocking the EDT is basically a convenience backpressure strategy in the GUI world to prevent the user from changing the application state whil