Possible race condition while using cancellation from subscribe().with()

[manofthepeace]

Hi Julien, sorry for the flood these days.

I am starting to play with the cancellation and I am not sure I fully understand how it works, or how it should work. Basically I am starting multiple "jobs" / pipelines, and I want to store their cancellations in a map, so a public api can cancel the jobs (if hell breaks lose). I also want to clean that map once the "job" is terminated.

If I do (simplified a lot..);

Map<String,Cancellable> jobs;
Cancellable myJob myUni.onTermination().invoke(()->jobs.remove(id)).subscribe.with(...);
jobs.add(id,myJob);

There is chances that the onTermination runs before the jobs.add. So the map will just get cruft long term.

I tried using the UniSubscription from the onSubscribe() something like this.

Map<String,Cancellable> jobs;
myUni
.onSubscribe().invoke(subscription->jobs.add(id,subscription))
.onTermination().invoke(()->jobs.remove(id))
.subscribe.with(...);

But when doing it this way, it seems like the onTermination, or even onCancellation are never called. I wonder why? Is there a way to ensure I can a cancellable, before the subscription might happen, or even finish?

The way I found is quite dirty, and I would really appreciate a better way. Basically its something like this pseudo code-ish

Map<String,Cancellable> jobs;
CountDownLatch latch = new CountDownLatch(1);
Cancellable myJob myUni
.onSubscription().invoke(()->latch.await())
.onTermination().invoke(()->jobs.remove(id)).subscribe.with(...);
jobs.add(id,myJob);
latch.countDown();

Thanks.
Alex

[jponge]

You might put the onSubscription operator at the bottom, just before the .subscribe() call. This will ensure that you receive the subscription for the rest of the pipeline (e.g., all the operators above onSubscription).

Note that the log() operator might help you to make sense of which events flow between operators.

Hope it helps

[manofthepeace]

At first glance this seems to work! I really did not know that the precedence of the onXXX had an incidence on the underlying behaviour. Is that documented somewhere? Otherwise I might try to contribute a bit on doc on that as it was not directly obvious to me.

Thanks so much for your quick response, appreciate.

[jponge]

Yes this is by design, each operator yields a new publisher, so the order does matter