# take Published articles for take. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Worth Reading: Things We Know about Network Queues DevFeed: [Worth Reading: Things We Know about Network Queues]() Original publisher: [Read original article]() Published: 2024-03-23T08:41:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Network](), [datacenter]() Tags: [article](), [data-center](), [network](), [qos](), [take](), [worth-reading]() ### AI overview The article recommends Avery Pennarun's piece on what is known about network queues and cautions readers to be skeptical of expensive big-buffer data center switches. ### Source excerpt Every time someone tries to persuade you to buy (expensive) big-buffer data center switches, take an antidote: the Things we (finally) know about network queues article by Avery Pennarun. ## When multiple subscribeOn()s do have effect DevFeed: [When multiple subscribeOn()s do have effect]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-11-29T12:33:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Code](), [Concurrent Programming]() Tags: [collect](), [concurrency](), [filter](), [flowable](), [io](), [main-thread](), [map](), [scheduler](), [subscribeon](), [take](), [thread](), [tutorials]() ### 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 ## Java 9 Flow API: taking and skipping DevFeed: [Java 9 Flow API: taking and skipping]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-30T20:44:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java 9](), [API](), [reactive]() Tags: [api](), [flow](), [flow-api](), [implementation](), [java-9](), [jdk](), [publisher](), [reactive](), [reactive-streams](), [skip](), [skipwhile](), [streams](), [subscriber](), [subscription](), [take](), [takeuntil](), [takewhile]() ### AI overview A tutorial on implementing take and skip-style operators with Java 9's Flow API. It explains how to limit a flow, cancel the upstream subscription when the limit is reached, complete the downstream subscriber, handle terminal events, and account for backpressure behavior. ### Source excerpt Introduction Limiting or skipping over parts of a flow is a very common task: either we are only interested in the first N items or we don't care about the first N items. Sometimes, N is unknown but we can decide, based on the current item, when to stop relaying items or, in contrast, when to start relaying items. Take(N) In concept, limiting a flow to a certain size should be straightforward: count the number of items received via onNext and when the limit is reached, issue a cancel() towards the upstream and onComplete() towards the downstream. public static Flow.Publisher take(Flow.Publisher source, long n) { return new TakePublisher<>(source, n); } The operator's implementation requires little state: static final class TakeSubscriber implements Flow.Subscriber { final Flow.Subscriber downstream; Flow.Subscription upstream; long remaining; TakeSubscriber( Flow.Subscriber downstream, long n) { this.downstream = downstream; this.remaining = n; } @Override public void onSubscribe(Flow.Subscription s) { // TODO implement } @Override public void onNext(T item) { // TODO implement } @Override public void onError(Throwable throwable) { // TODO implement } @Override public void onComplete() { // TODO implement } } In its simplest form, there is no need for intercepting the request() and cancel() calls from the downstream: these can be passthrought, however, since the operator has to stop the sequence upon reaching the limit (remaining == 0), the upstream's Flow.Subscriber has to be stored. @Override public void onSubscribe(Flow.Subscription s) { this.upstream = s; downstream.onSubscribe(s); } In onSubscribe, we only have to store the Flow.Subscription and forward it to the downstream. @Override public void onNext(T item) { long r = remaining; if (r > 0L) { remaining = --r; downstream.onNext(item); if (r == 0) { upstream.cancel(); downstream.onComplete(); } } } While remaining is positive, we decrement it and save it into its field foll