Skip to content

Javadoc updates for RXJava Issue 6289 #6308

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 16, 2018
Merged

Javadoc updates for RXJava Issue 6289 #6308

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1f0450b
Javadoc updates for RXJava Issue 6289
pkamath2 Nov 16, 2018
00d7158
With review comments on issue 6289
pkamath2 Nov 16, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions src/main/java/io/reactivex/Flowable.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10345,6 +10345,14 @@ public final Disposable forEachWhile(final Predicate<? super T> onNext, final Co
* is subscribed to. For this reason, in order to avoid memory leaks, you should not simply ignore those
* {@code GroupedPublisher}s that do not concern you. Instead, you can signal to them that they may
* discard their buffers by applying an operator like {@link #ignoreElements} to them.
* <p>
* Note that the {@link GroupedFlowable}s should be subscribed to as soon as possible, otherwise,
* the unconsumed groups may starve other groups due to the internal backpressure
* coordination of the {@code groupBy} operator. Such hangs can be usually avoided by using
* {@link #flatMap(Function, int)} or {@link #concatMapEager(Function, int, int)} and overriding the default maximum concurrency
* value to be greater or equal to the expected number of groups, possibly using
* {@code Integer.MAX_VALUE} if the number of expected groups is unknown.
*
* <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>Both the returned and its inner {@code Publisher}s honor backpressure and the source {@code Publisher}
Expand Down Expand Up @@ -10385,6 +10393,13 @@ public final <K> Flowable<GroupedFlowable<K, T>> groupBy(Function<? super T, ? e
* is subscribed to. For this reason, in order to avoid memory leaks, you should not simply ignore those
* {@code GroupedPublisher}s that do not concern you. Instead, you can signal to them that they may
* discard their buffers by applying an operator like {@link #ignoreElements} to them.
* <p>
* Note that the {@link GroupedFlowable}s should be subscribed to as soon as possible, otherwise,
* the unconsumed groups may starve other groups due to the internal backpressure
* coordination of the {@code groupBy} operator. Such hangs can be usually avoided by using
* {@link #flatMap(Function, int)} or {@link #concatMapEager(Function, int, int)} and overriding the default maximum concurrency
* value to be greater or equal to the expected number of groups, possibly using
* {@code Integer.MAX_VALUE} if the number of expected groups is unknown.
* <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>Both the returned and its inner {@code Publisher}s honor backpressure and the source {@code Publisher}
Expand Down Expand Up @@ -10428,6 +10443,14 @@ public final <K> Flowable<GroupedFlowable<K, T>> groupBy(Function<? super T, ? e
* is subscribed to. For this reason, in order to avoid memory leaks, you should not simply ignore those
* {@code GroupedPublisher}s that do not concern you. Instead, you can signal to them that they may
* discard their buffers by applying an operator like {@link #ignoreElements} to them.
* <p>
* Note that the {@link GroupedFlowable}s should be subscribed to as soon as possible, otherwise,
* the unconsumed groups may starve other groups due to the internal backpressure
* coordination of the {@code groupBy} operator. Such hangs can be usually avoided by using
* {@link #flatMap(Function, int)} or {@link #concatMapEager(Function, int, int)} and overriding the default maximum concurrency
* value to be greater or equal to the expected number of groups, possibly using
* {@code Integer.MAX_VALUE} if the number of expected groups is unknown.
*
* <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>Both the returned and its inner {@code Publisher}s honor backpressure and the source {@code Publisher}
Expand Down Expand Up @@ -10473,6 +10496,14 @@ public final <K, V> Flowable<GroupedFlowable<K, V>> groupBy(Function<? super T,
* is subscribed to. For this reason, in order to avoid memory leaks, you should not simply ignore those
* {@code GroupedPublisher}s that do not concern you. Instead, you can signal to them that they may
* discard their buffers by applying an operator like {@link #ignoreElements} to them.
* <p>
* Note that the {@link GroupedFlowable}s should be subscribed to as soon as possible, otherwise,
* the unconsumed groups may starve other groups due to the internal backpressure
* coordination of the {@code groupBy} operator. Such hangs can be usually avoided by using
* {@link #flatMap(Function, int)} or {@link #concatMapEager(Function, int, int)} and overriding the default maximum concurrency
* value to be greater or equal to the expected number of groups, possibly using
* {@code Integer.MAX_VALUE} if the number of expected groups is unknown.
*
* <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>Both the returned and its inner {@code Publisher}s honor backpressure and the source {@code Publisher}
Expand Down Expand Up @@ -10521,6 +10552,14 @@ public final <K, V> Flowable<GroupedFlowable<K, V>> groupBy(Function<? super T,
* is subscribed to. For this reason, in order to avoid memory leaks, you should not simply ignore those
* {@code GroupedPublisher}s that do not concern you. Instead, you can signal to them that they may
* discard their buffers by applying an operator like {@link #ignoreElements} to them.
* <p>
* Note that the {@link GroupedFlowable}s should be subscribed to as soon as possible, otherwise,
* the unconsumed groups may starve other groups due to the internal backpressure
* coordination of the {@code groupBy} operator. Such hangs can be usually avoided by using
* {@link #flatMap(Function, int)} or {@link #concatMapEager(Function, int, int)} and overriding the default maximum concurrency
* value to be greater or equal to the expected number of groups, possibly using
* {@code Integer.MAX_VALUE} if the number of expected groups is unknown.
*
* <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>Both the returned and its inner {@code Publisher}s honor backpressure and the source {@code Publisher}
Expand Down Expand Up @@ -10617,6 +10656,14 @@ public final <K, V> Flowable<GroupedFlowable<K, V>> groupBy(Function<? super T,
* is subscribed to. For this reason, in order to avoid memory leaks, you should not simply ignore those
* {@code GroupedFlowable}s that do not concern you. Instead, you can signal to them that they may
* discard their buffers by applying an operator like {@link #ignoreElements} to them.
* <p>
* Note that the {@link GroupedFlowable}s should be subscribed to as soon as possible, otherwise,
* the unconsumed groups may starve other groups due to the internal backpressure
* coordination of the {@code groupBy} operator. Such hangs can be usually avoided by using
* {@link #flatMap(Function, int)} or {@link #concatMapEager(Function, int, int)} and overriding the default maximum concurrency
* value to be greater or equal to the expected number of groups, possibly using
* {@code Integer.MAX_VALUE} if the number of expected groups is unknown.
*
* <dl>
* <dt><b>Backpressure:</b></dt>
* <dd>Both the returned and its inner {@code GroupedFlowable}s honor backpressure and the source {@code Publisher}
Expand Down