# ordered merge

Published articles for ordered merge.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Java 9 Flow API: ordered merge

DevFeed: [Java 9 Flow API: ordered merge](<https://devfeed.tech/articles/java-9-flow-api-ordered-merge-24810.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2017/09/java-9-flow-api-ordered-merge.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2017-09-11T14:46:00Z

Content type: tutorial

Language: en

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

Topics: [Java](<https://devfeed.tech/topics/java.md>), [Java 9](<https://devfeed.tech/topics/java-9.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [batching](<https://devfeed.tech/tags/batching.md>), [flow](<https://devfeed.tech/tags/flow.md>), [flow-api](<https://devfeed.tech/tags/flow-api.md>), [java](<https://devfeed.tech/tags/java.md>), [java-9](<https://devfeed.tech/tags/java-9.md>), [merge](<https://devfeed.tech/tags/merge.md>), [ordered-merge](<https://devfeed.tech/tags/ordered-merge.md>), [queue](<https://devfeed.tech/tags/queue.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [sequences](<https://devfeed.tech/tags/sequences.md>), [stream](<https://devfeed.tech/tags/stream.md>)

### AI overview

This article explains why zip() and flatMap() are unsuitable for merging multiple ordered event sequences while preserving order. It presents an orderedMerge() operator that selects the smallest or largest available item, requires a fixed number of source sequences, and discusses how unordered sources produce priority-queue-like output. It also introduces prefetching, queues, coordination, batching, and stable-prefetch backpressure for an inner consumer implementation.

### Source excerpt

Introduction Sometimes, one has several ordered sequences of events and would like to merge them into one single flow. Since one element from a sequence should come before another element in another sequence, we need a way to keep comparing elements with each other from different sequences. Unfortunately, zip() doesn't work because it takes a row of available items and item #2 from sequence #2 may come before item #1 from stream #3. Plus, if one stream is shorter than the others, the end sequence stops. Similarly, flatMap() doesn't work because it takes the next item from any inner source sequence the moment it is available without any ordering considerations at that point. At least it emits all items from all sources (provided there are no errors of course). Therefore, we need something between the two operators: one that collects up a row of items from the sources, decides which is the smallest/largest of them based on some comparison logic and only emits that. It then awaits a fresh item from that specific source (or completion) and repeats the picking of the smallest/largest item as long as there are requests for it. Such operator, let's call it orderedMerge(), has an implication about the number of its inner source sequences: it has to be fixed. The reason for it is that it has to pick the smallest/largest of the available items in order for the output to be in order. If there is still a source missing, it can't know for sure the others are smaller/larger that any of the upcoming item from that missing source will produce. The second implication is, what happens if the sources themselves are not ordered? The logic presented in this post still works, but the end output won't be totally ordered. It will act like some priority queue instead: picking important items first before turning to less important ones. The inner consumer Operators handling multiple sources often need a way to prefetch item from these sources and give out them on demand to some joining logic