1202: prioritized merge #1205

ctoomey · 2020-06-19T05:06:14Z

Incomplete draft for #1202 for review/discussion. Tests to follow as appropriate.

Avasil · 2020-06-23T08:49:52Z

.../shared/src/main/scala/monix/reactive/internal/builders/MergePrioritizedListObservable.scala

+        priority.compareTo(o.priority)
+    }
+
+    val pq = new PriorityBlockingQueue[PQElem](sources.size)


Could we use normal PriorityQueue instead of a blocking one? It seems like the access is synchronized anyway

Sure, I will look at replacing it and adding necessary synchronization, then adding tests.

Otherwise it looks good?

Sorry, I haven't got a moment to take a close look, but it seems to look good.

I think it's not too far from mergeMapPrioritized version If you'd like to go further:

onNext of the source Observable (upstream) would add a new Observable to the composite instead of doing it from the starting list

RefCountObservable is used to control the number of active children and their lifecycle

It would be awesome to support different overflow strategies, but it would require to update BufferedSubscriber to allow priority queues. The implementation is in AbstractBackPressuredBufferedSubscriber for Back-Pressure strategy. Unfortunately I don't know if there is a good implementation of concurrent priority queue out there. I imagine it's too much work, and I don't have capacity to work on it right now so I suppose we can stay with the current behavior which is a back-pressure with bufferSize of 0.

If you don't feel like doing it - that's okay, mergePrioritizedList is already better than the status quo

It might also be nice to add a benchmark vs normal merge, but that's just my curiosity and completely optional.

Since updating BufferedSuscriber would be lots of work I kept my implementation as is. I swapped out the Java PriorityBlockingQueue for the Scala mutable.PriorityQueue, and added tests.

ctoomey · 2020-08-04T19:26:13Z

@Avasil will you go ahead and merge this, or is there anything else needed? Thanks.

alexandru · 2020-08-05T09:55:48Z

monix-reactive/shared/src/main/scala/monix/reactive/Observable.scala

+    * sources have items available. If items are available from sources with the
+    * same priority, the order is undefined.
+    */
+  def mergePrioritizedList[A](sources: Observable[A]*)(priorities: Seq[Int]): Observable[A] = {


Very interesting implementation @ctoomey.

I do have one suggestion about this signature ... it's not clear that the priorities should match the sources and there's no reason for it.

How about ...

def mergePrioritizedList[A](sources: (Int, Observable[A])*): Observable[A]

Then you could do ...

Observable.mergePrioritizedList( 1 -> observable1, 2 -> observable2, //... )

That way the signature is clearer, and you don't need that runtime assert in the implementation.

Ya I'd prefer that signature too and in fact had it that way originally, but decided to match the way Akka streams did it. I'll change it.

alexandru · 2020-08-05T10:02:56Z

@ctoomey btw, thanks for the contribution, looking good, just dropped a suggestion on the signature . Will try and take it for a test drive.

@Avasil don't hold the merge on my account 🙂

ctoomey · 2020-08-06T21:27:26Z

CI failed due to unrelated test monix.catnap.ConcurrentChannelJVMParallelism8Suite failure. Will somebody please re-trigger it?

ctoomey · 2020-08-07T19:24:49Z

Another unrelated test failure. Please re-run the CI, thanks.

Avasil · 2020-08-07T19:35:24Z

I'm not sure about ConcurrentChannelJVMParallelism8Suite but I know about InputObservableSuite - I'll fix it during the weekend and review your PR. :)

ctoomey · 2020-08-07T21:19:46Z

Thanks @Avasil -- looking forward to having this merged and released -- any idea when you'll do the next release?

Avasil · 2020-08-07T21:28:25Z

I wanted to do the next release with #1213 but it might take a while and we could do something earlier.
We can also release a snapshot any time

ctoomey · 2020-08-07T23:11:26Z

It'd be great to have a release soon after this PR is merged, if that's not too much trouble.

Avasil

It's looking good @ctoomey ! Thank you for the effort and sorry for slow responses, I've been away for the last two weeks.

I'm wondering about how strict should we be about prioritizing sources.
e.g.

val source =
  Observable.mergePrioritizedList((2, Observable(1, 1, 1, 1, 1, 1)), (1, Observable(2, 2, 2, 2, 2, 2)))

val f = source.toListL.runToFuture

All elements are available immediately for both sources, should it always return List(1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2)?

BTW @AlecZorab Do you think the issue you mentioned is fixed now? It seems like the comment was deleted

Avasil · 2020-08-09T19:06:18Z

.../shared/src/main/scala/monix/reactive/internal/builders/MergePrioritizedListObservable.scala

+
+    // MUST BE synchronized by `lock`
+    def signalOnNext(): Future[Ack] =
+      lock.synchronized {


redundant synchronize - comment already mentions it and it is done in onNext

Avasil · 2020-08-09T19:07:40Z

.../shared/src/main/scala/monix/reactive/internal/builders/MergePrioritizedListObservable.scala

+      if (isDone) Stop else out.onNext(a)
+    }
+
+    def processNext(): Future[Ack] = {


needs a comment: // MUST BE synchronized by `lock`

Avasil · 2020-08-09T19:33:03Z

monix-reactive/shared/src/main/scala/monix/reactive/Observable.scala

@@ -6056,6 +6056,19 @@ object Observable extends ObservableDeprecatedBuilders {
    }
  }

+  /** Given a sequence of priority/observable pairs, combines them


Might be good to mention whether higher value is higher priority

AlecZorab · 2020-08-10T09:31:00Z

I'm not sure if the issue I spotted is fixed or not.

It looks like signalOnComplete can still trigger before the final message gets processed, but maybe there's some subtlety to the execution model that I'm missing?

The example that springs to mind:

Observable calls onNext with its final value, there are higher priority values waiting, so it gets put into the pqueue. The observable is now complete, so it calls onComplete, triggering signalOnComplete. This can't acquire the lock, so it blocks. In the async case of signalOnNext, there's now a race where the waiting signalOnComplete can enter the lock before the value processing happens.

But maybe the system invariants forbid that from happening?

ctoomey · 2020-08-10T20:29:03Z

I'm wondering about how strict should we be about prioritizing sources.

Good question. I thought more about this and how to document it and came up w/ the following doc. update that'll be in the next commit. One improvement this triggered was changing the order of subscribing to the sources from the given order to prioritized order, such that if multiple sources have items immediately available, the highest priority ones will come through first.

  /** Given a sequence of priority/observable pairs, combines them into a new
    * observable that eagerly emits source items downstream as soon as demand is
    * signaled, choosing the item from the highest priority (greater numbers
    * mean higher priority) source when items from multiple sources are
    * available. If items are available from multiple sources with the same
    * highest priority, one of them is chosen arbitrarily.
    *
    * Source items are buffered only to the extent necessary to accommodate
    * backpressure from downstream, and thus if only a single item is available
    * when demand is signaled, it will be emitted regardless of priority.
    *
    * Backpressure is propagated from downstream to the source observables, so
    * that items from a given source will always be emitted downstream in the
    * same order as received from the source, and at most a single item from a
    * given source will be in flight at a time.
    */

In your example, the proposed ordering is not guaranteed though, as the sequencing of the sources calling onNext is non-deterministic and so per the eager downstream emitting, so is the item ordering.

Avasil · 2020-08-10T21:39:26Z

Note that the normal Observable.merge uses an underlying back-pressured buffer. An implementation using bounded buffers for a prioritized merge could be more complicated, but I'd like for us to give it a try.

So in case your implementation isn't back-pressured, that is fine for now, but then I'd like to know if you'd be interested in exploring an alternative using bounded buffers afterwards, to make this safer. I can provide you with some ideas if interested.

Could we provide the current implementation with API that would allow us to add customizable back-pressure in later release?
If I remember correctly, @ctoomey implementation supports OverflowStrategy.BackPressure(1) which ironically is not yet possible for other operators :D Though even if we add a new parameter with that default it won't be consistent with other operators where it is os: OverflowStrategy[B] = OverflowStrategy.Default and I need to double check if it's binary compatible

Avasil · 2020-08-10T21:47:18Z

.../shared/src/main/scala/monix/reactive/internal/builders/MergePrioritizedListObservable.scala

+            case Continue =>
+              isDone = true
+              out.onComplete()
+              completePromises()


Regarding the issue:

The key is that so long as there are items the downstream hasn't yet processed, lastAck will remain a Future[Ack], and signalOnComplete won't call out.onComplete until that future completes, i.e., downstream has finished processing all pending items including the last one from the last source.

Take the simplest case of your example: 2 sources w/ 1 item each:

Source A calls onNext, item gets sent downstream: lastAck = Future[Ack for A's item]
Source A calls onComplete: completedCount = 1
Source B calls onNext, item gets queued: lastAck = Future[Ack for A's item].flatMap(Future[Ack for B's item])
Source B calls onComplete: completedCount = 2; lastAck.onComplete { ... out.onComplete }

Looking at the contract: https://monix.io/docs/3x/reactive/observers.html#contract

Back-pressure for onComplete and onError is optional: when calling onComplete or onError you are not required to wait on the Future[Ack] of the previous onNext.

It implies that Source B could call:

out.onNext(lastElem) out.onComplete()

In that case, we could send remaining elements from the queue to the downstream instead of completing each promise with Stop.

In that case, we could send remaining elements from the queue to the downstream instead of completing each promise with Stop.

So long as the downstream returns Continue and none of the upstreams call onError, the downstream will always get all the items emitted by the upstreams. That's what the "should push all items downstream before calling onComplete" test is verifying. Again:

The key is that so long as there are items the downstream hasn't yet processed, lastAck will remain a Future[Ack], and signalOnComplete won't call out.onComplete (or completePromises) until that future completes, i.e., downstream has finished processing all pending items including the last one from the last source.

alexandru · 2020-08-10T21:58:32Z

Could we provide the current implementation with API that would allow us to add customizable back-pressure in later release?

If I remember correctly, @ctoomey implementation supports OverflowStrategy.BackPressure(1) which ironically is not yet possible for other operators :D Though even if we add a new parameter with that default it won't be consistent with other operators where it is os: OverflowStrategy[B] = OverflowStrategy.Default and I need to double check if it's binary compatible

We can't add an extra parameter, if that's what you mean. But should we add a buffered alternative, can always add an overload, with the same name or with a different name.

alexandru · 2020-08-10T22:07:25Z

Note I'm fine with a BackPressure(1) behavior, that's valuable in itself.

If some buffering is desired however, it would probably be incorrect to add it after the merge, because you can buffer lower-priority items, and keep the high priority items from being processed.

So I'd like us to open an issue for a buffered variant too. I'm thinking that each priority can have its own buffer and then a loop would go and select between them, cycling from high priority to low priority.

alexandru · 2020-08-10T22:10:34Z

... speaking of this, this is how RxJava built a kick-ass merge operation, last time I checked. They created multiple buffers (concurrent queues), assigning them per observable being merged, to reduce the contention on the producers side. But this isn't very relevant to this PR. Mentioning it to keep it in mind for the future.

Note: I enabled GitHub Actions, so a "stable" "snapshot" version will be published as soon as this PR is merged.

ctoomey · 2020-08-11T03:24:00Z

.../shared/src/main/scala/monix/reactive/internal/builders/MergePrioritizedListObservable.scala

+              throw e
+          }
+      }
+    }


Added the above logic to ensure that we complete the upstream onNext promises when the downstream stops or errors early while we still have pending upstream items. Added tests to verify as well.

We could use our syncOnStopOrFailure syntax here, should be more efficient

Much nicer, thanks.

ctoomey · 2020-08-11T03:34:04Z

So I'd like us to open an issue for a buffered variant too. I'm thinking that each priority can have its own buffer and then a loop would go and select between them, cycling from high priority to low priority.

Created #1227

Note: I enabled GitHub Actions, so a "stable" "snapshot" version will be published as soon as this PR is merged.

Great, thanks @alexandru

AlecZorab · 2020-08-11T10:47:57Z

So having done some println debugging, I'm convinced that the issue I highlighted isn't an issue any more. The subtlety in the implementation that I missed is in the way the chaining of futures works in signalOnNext. For the early completion I was thinking about to occur, you'd have to have an item in the pqueue waiting to be sent, whilst also having lastAck == Continue, which isn't a reachable state.

@ctoomey, my apologies for taking so long to understand what you were talking about

AlecZorab · 2020-08-11T11:07:36Z

...tive/shared/src/test/scala/monix/reactive/internal/operators/MergePrioritizedListSuite.scala

+
+    def unsafeSubscribeFn(subscriber: Subscriber[A]): Cancelable = {
+      val onNext = subscriber.onNext(elem)
+      onNext.onComplete(_ => subscriber.onComplete())


since it's allowed in the contract, it might be a better test to change this to call onComplete immediately, rather than waiting for onNext to complete. Having tried it, the test still passes, so it's really just a case of making it a little bit more stringent

ctoomey · 2020-08-11T18:57:18Z

So having done some println debugging, I'm convinced that the issue I highlighted isn't an issue any more. The subtlety in the implementation that I missed is in the way the chaining of futures works in signalOnNext. For the early completion I was thinking about to occur, you'd have to have an item in the pqueue waiting to be sent, whilst also having lastAck == Continue, which isn't a reachable state.

@ctoomey, my apologies for taking so long to understand what you were talking about

No problem, good to be sure for this kind of thing.

ctoomey · 2020-08-11T19:25:44Z

@Avasil will you please merge if there's nothing else? Thanks

alexandru · 2020-08-11T19:37:29Z

@Avasil at this point I think we should just merge, and let @ctoomey test with the published version. If there's anything wrong, I'm sure he'll be around to help.

ctoomey · 2020-08-11T21:29:41Z

@Avasil at this point I think we should just merge, and let @ctoomey test with the published version. If there's anything wrong, I'm sure he'll be around to help.

For sure

Avasil · 2020-08-11T21:36:01Z

Awesome, I've merged into series/3.x but I'm not sure if it has an automatic release now?

Avasil · 2020-08-11T21:36:59Z

And how do we go about keeping consistency between series, should we open a PR from this branch and target 4.x.?

* 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * Fix unrelated InputStreamObservableSuite bug that failed build * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge * 1202: prioritized merge

alexandru · 2020-08-12T06:10:27Z

Awesome, I've merged into series/3.x but I'm not sure if it has an automatic release now?

It didn't, I introduced a parameter in our secrets, called AUTO_PUBLISH_SERIES_3X, and it was set to false. I've set it to true and re-running the build, will let you know when it's ready.

And how do we go about keeping consistency between series, should we open a PR from this branch and target 4.x.?

Unfortunately we have to start making incompatible changes, and maintaining two branches is inevitable, because the 4.x release will not be stable enough to release for a couple of months.

So yes, new developments that are compatible with Monix 3.x should target the series/3.x branch, which is now the main branch, and then we can back-port the changes. Fortunately we have been using "squash" when merging, keeping our history linear. So I just did this in the series/4.x branch:

git cherry-pick 1a5b9b1b41eaa2a1e955302e741a6daab1ff73f6

In this case it was clear, no PRs needed, I just committed it. The author could do that too, in which case a PR would be needed. And a PR would also be needed in case of conflicts.

alexandru · 2020-08-12T06:41:22Z

We have version 3.2.2+37-1a5b9b1b published.

ctoomey · 2020-08-12T18:12:21Z

We have version 3.2.2+37-1a5b9b1b published.

@alexandru the monix-internal-jctools artifact is missing:

[info] downloading https://repo1.maven.org/maven2/io/monix/monix_2.12/3.2.2+37-1a5b9b1b/monix_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] downloading https://repo1.maven.org/maven2/io/monix/monix-catnap_2.12/3.2.2+37-1a5b9b1b/monix-catnap_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] downloading https://repo1.maven.org/maven2/io/monix/monix-eval_2.12/3.2.2+37-1a5b9b1b/monix-eval_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] downloading https://repo1.maven.org/maven2/io/monix/monix-reactive_2.12/3.2.2+37-1a5b9b1b/monix-reactive_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] downloading https://repo1.maven.org/maven2/org/typelevel/cats-effect_2.12/2.1.4/cats-effect_2.12-2.1.4.jar ...
[info] downloading https://repo1.maven.org/maven2/io/monix/monix-tail_2.12/3.2.2+37-1a5b9b1b/monix-tail_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] downloading https://repo1.maven.org/maven2/io/monix/monix-java_2.12/3.2.2+37-1a5b9b1b/monix-java_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] downloading https://repo1.maven.org/maven2/io/monix/monix-execution_2.12/3.2.2+37-1a5b9b1b/monix-execution_2.12-3.2.2+37-1a5b9b1b.jar ...
[info] 	[SUCCESSFUL ] io.monix#monix_2.12;3.2.2+37-1a5b9b1b!monix_2.12.jar (393ms)
[info] 	[SUCCESSFUL ] io.monix#monix-java_2.12;3.2.2+37-1a5b9b1b!monix-java_2.12.jar (776ms)
[info] 	[SUCCESSFUL ] io.monix#monix-catnap_2.12;3.2.2+37-1a5b9b1b!monix-catnap_2.12.jar (1109ms)
[info] 	[SUCCESSFUL ] io.monix#monix-tail_2.12;3.2.2+37-1a5b9b1b!monix-tail_2.12.jar (1255ms)
[info] 	[SUCCESSFUL ] org.typelevel#cats-effect_2.12;2.1.4!cats-effect_2.12.jar (1354ms)
[info] 	[SUCCESSFUL ] io.monix#monix-eval_2.12;3.2.2+37-1a5b9b1b!monix-eval_2.12.jar (1358ms)
[info] 	[SUCCESSFUL ] io.monix#monix-execution_2.12;3.2.2+37-1a5b9b1b!monix-execution_2.12.jar (1365ms)
[info] 	[SUCCESSFUL ] io.monix#monix-reactive_2.12;3.2.2+37-1a5b9b1b!monix-reactive_2.12.jar (1728ms)
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 	::          UNRESOLVED DEPENDENCIES         ::
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 	:: io.monix#monix-internal-jctools_2.12;3.2.2+37-1a5b9b1b: not found
[warn] 	::::::::::::::::::::::::::::::::::::::::::::::
[warn] 
[warn] 	Note: Unresolved dependencies path:
[warn] 		io.monix:monix-internal-jctools_2.12:3.2.2+37-1a5b9b1b (/Users/christoomey/unix/liv/service-template/api/build.sbt#L40-75)
[warn] 		  +- io.monix:monix-execution_2.12:3.2.2+37-1a5b9b1b (/Users/christoomey/unix/liv/service-template/api/build.sbt#L40-75)
[warn] 		  +- io.monix:monix-catnap_2.12:3.2.2+37-1a5b9b1b (/Users/christoomey/unix/liv/service-template/api/build.sbt#L40-75)
[warn] 		  +- io.monix:monix-eval_2.12:3.2.2+37-1a5b9b1b (/Users/christoomey/unix/liv/service-template/api/build.sbt#L40-75)
[warn] 		  +- io.monix:monix-reactive_2.12:3.2.2+37-1a5b9b1b (/Users/christoomey/unix/liv/service-template/api/build.sbt#L40-75)
[warn] 		  +- io.monix:monix_2.12:3.2.2+37-1a5b9b1b (/Users/christoomey/unix/liv/service-template/api/build.sbt#L40-75)

alexandru · 2020-08-13T08:50:13Z

@ctoomey sorry, I updated JCTools, and in the process I ended up "shading" it, but forgot to "aggregate" it, so it didn't get published.

We're fixing it.

alexandru · 2020-08-13T09:34:19Z

@ctoomey try 3.2.2+41-615286ba

ctoomey · 2020-08-13T19:24:58Z

Thanks @alexandru, looks good now.

1202: prioritized merge

ea61f60

ctoomey mentioned this pull request Jun 19, 2020

Support merging observables #1202

Closed

Avasil reviewed Jun 23, 2020

View reviewed changes

ctoomey added 2 commits July 23, 2020 14:50

1202: prioritized merge

0b1c831

1202: prioritized merge

c31beda

monix deleted a comment from Avasil Jul 27, 2020

monix deleted a comment from ctoomey Jul 27, 2020

monix deleted a comment from AlecZorab Jul 27, 2020

monix deleted a comment from ctoomey Jul 27, 2020

Fix unrelated InputStreamObservableSuite bug that failed build

0e5844a

alexandru reviewed Aug 5, 2020

View reviewed changes

1202: prioritized merge

1b6c1c4

1202: prioritized merge

00f57ee

Avasil reviewed Aug 9, 2020

View reviewed changes

ctoomey added 3 commits August 10, 2020 13:30

1202: prioritized merge

88e6a04

1202: prioritized merge

9b04ba4

Merge branch 'master' into 1202-merge

affe39e

Avasil reviewed Aug 10, 2020

View reviewed changes

ctoomey added 3 commits August 10, 2020 19:50

1202: prioritized merge

99cc03d

1202: prioritized merge

df122f7

1202: prioritized merge

c23d1cf

ctoomey commented Aug 11, 2020

View reviewed changes

ctoomey mentioned this pull request Aug 11, 2020

Support merging observables with parameterized OverflowStrategy #1227

Open

AlecZorab reviewed Aug 11, 2020

View reviewed changes

alexandru changed the base branch from master to series/3.x August 11, 2020 18:14

1202: prioritized merge

4d52bfc

Avasil merged commit 1a5b9b1 into monix:series/3.x Aug 11, 2020

Avasil added this to the 3.3.0 milestone Sep 13, 2020

1202: prioritized merge #1205

1202: prioritized merge #1205

Conversation

ctoomey commented Jun 19, 2020

Choose a reason for hiding this comment

ctoomey Jun 27, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ctoomey commented Aug 4, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexandru commented Aug 5, 2020 • edited Loading

ctoomey commented Aug 6, 2020

ctoomey commented Aug 7, 2020

Avasil commented Aug 7, 2020

ctoomey commented Aug 7, 2020

Avasil commented Aug 7, 2020

ctoomey commented Aug 7, 2020

Avasil left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlecZorab commented Aug 10, 2020

ctoomey commented Aug 10, 2020

Avasil commented Aug 10, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexandru commented Aug 10, 2020

alexandru commented Aug 10, 2020

alexandru commented Aug 10, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ctoomey commented Aug 11, 2020

AlecZorab commented Aug 11, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ctoomey commented Aug 11, 2020

ctoomey commented Aug 11, 2020

alexandru commented Aug 11, 2020

ctoomey commented Aug 11, 2020

Avasil commented Aug 11, 2020

Avasil commented Aug 11, 2020

alexandru commented Aug 12, 2020 • edited Loading

alexandru commented Aug 12, 2020

ctoomey commented Aug 12, 2020

alexandru commented Aug 13, 2020

alexandru commented Aug 13, 2020

ctoomey commented Aug 13, 2020

ctoomey Jun 27, 2020 •

edited

Loading

alexandru commented Aug 5, 2020 •

edited

Loading

alexandru commented Aug 12, 2020 •

edited

Loading