# ExecutorService Published articles for ExecutorService. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Awaitility DevFeed: [Awaitility]() Original publisher: [Read original article]() Published: 2019-10-10T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Library](), [Testing](), [Concurrency](), [async](), [Code]() Tags: [asynchronous](), [concurrency](), [examples](), [executorservice](), [library](), [multithreading](), [queue](), [testing](), [threads]() ### AI overview This tutorial introduces Awaitility, a small library for testing asynchronous code. It explains how Awaitility can express expectations for multithreaded systems concisely, using a producer-consumer example with a queue. ### Source excerpt If you are not working with multithreading programming and don't have to test any asynchronous code then this post will probably do you nothing good. But if you have ever struggled with testing some logic running in multiple threads and you don't know Awaitility. A small library helps testing asynchronous code. If you've never heard of it then you should continue reading. Read more ## Java 9 Flow API: switching threads DevFeed: [Java 9 Flow API: switching threads]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-21T10:49:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java](), [Java 9](), [API](), [reactive](), [Concurrency](), [Concurrent Programming]() Tags: [asynchronous](), [executor](), [executorservice](), [flow](), [flow-api](), [idea](), [intellij](), [java](), [java-9](), [jvm](), [main-thread](), [observeon](), [publisher](), [thread](), [threading](), [threads]() ### AI overview This tutorial explains how to switch execution between threads in reactive flows using Java 9's Flow API. It compares embedding thread switching in operators with a separate observeOn stage, then outlines an observeOn implementation based on Executor, asynchronous boundaries, bounded queues, and request management. ### Source excerpt Introduction Ensuring certain computations happen on the right thread, usually off the main thread, is a very common development task when dealing with reactive flows. When building up tools for Java 9's Flow API, one can decide to add this thread-switching support to each operator directly - see the range() operator from the start of the series -, or have a standalone stage for this purpose. This is a tradeoff. Inlining thread switching avoids bogging down the source thread like the thread-stealing behavior of most of the queue-drain approach presented so far. A separate operator allows better composition and may even allow working with exotic asynchrony-providing components. The observeOn operator In Java, threading support is provided via the Executor, ExecutorService and ScheduledExecutorService-based API. Executor is is the most basic one of them which only provides a single execute(Runnable) method. This allows creating an Executor from a lambda: Executor trampoline = Runnable::run; Executor swing = SwingUtilities::invokeLater; Executor pool = ForkJoinPool.commonPool(); As the least common denominator, we'll use Executor in defining our observeOn operator: public static Flow.Publisher observeOn( Flow.Publisher source, Executor exec, int prefetch) { return new ObserveOnPublisher<>(source, exec, prefetch); } Crossing an asynchronous boundary requires the temporary storage of an event until the other side can pick it up. The queue-drain approach can provide a nice bounded queue we can size with prefetch. In addition, the so-called stable-prefetch request management (shown in the mapFilter operator before) allows minimizing the overhead of requesting more items. First, let's see the skeleton of the operator's main Flow.Subscriber implementation: static final class ObserveOnSubscriber implements Flow.Subscriber, Flow.Subscription, Runnable { final Flow.Subscriber downstream; final Executor exec; final int prefetch; final Queue queue; F ## SubscribeOn and ObserveOn DevFeed: [SubscribeOn and ObserveOn]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2016-03-31T12:55:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Programming](), [reactive](), [User Experience](), [Android](), [GUI]() Tags: [backpressure](), [blocking](), [cancellation](), [executorservice](), [main-thread](), [observeon](), [reactive](), [rxjava](), [subscribeon](), [thread]() ### 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