How to repeat Mono while not empty - spring-webflux

I have a method which returns like this!
Mono<Integer> getNumberFromSomewhere();
I need to keep calling this until it has no more items to emit. That is I need to make this as Flux<Integer>.
One option is to add repeat. the point is - I want to stop when the above method emits the first empty signal.
Is there any way to do this? I am looking for a clean way.

A built-in operator that does that (although it is intended for "deeper" nesting) is expand.
expand naturally stops expansion when the returned Publisher completes empty.
You could apply it to your use-case like this:
//this changes each time one subscribes to it
Mono<Integer> monoWithUnderlyingState;
Flux<Integer> repeated = monoWithUnderlyingState
.expand(i -> monoWithUnderlyingState);

I'm not aware of a built-in operator which would do the job straightaway. However, it can be done using a wrapper class and a mix of operators:
Flux<Integer> repeatUntilEmpty() {
return getNumberFromSomewhere()
.map(ResultWrapper::new)
.defaultIfEmpty(ResultWrapper.EMPTY)
.repeat()
.takeWhile(ResultWrapper::isNotEmpty)
}
// helper class, not necessarily needs to be Java record
record ResultWrapper(Integer value) {
public static final ResultWrapper EMPTY = new ResultWrapper(null);
public boolean isNotEmpty() {
return value != null;
}
}

Related

Async Wait Efficient Execution

I need to iterate 100's of ids in parallel and collect the result in list. I am trying to do it in following way
val context = newFixedThreadPoolContext(5, "custom pool")
val list = mutableListOf<String>()
ids.map {
val result:Deferred<String> = async(context) {
getResult(it)
}
//list.add(result.await()
}.mapNotNull(result -> list.add(result.await())
I am getting error at
mapNotNull(result -> list.add(result.await())
as await method is not available. Why await is not applicable at this place? Instead commented line
//list.add(result.await()
is working fine.
What is the best way to run this block in parallel using coroutine with custom thread pool?
Generally, you go in the right direction: you need to create a list of Deferred and then await() on them.
If this is exactly the code you are using then you did not return anything from your first map { } block, so you don't get a List<Deferred> as you expect, but List<Unit> (list of nothing). Just remove val result:Deferred<String> = - this way you won't assign result to a variable, but return it from the lambda. Also, there are two syntactic errors in the last line: you used () instead of {} and there is a missing closing parenthesis.
After these changes I believe your code will work, but still, it is pretty weird. You seem to mix two distinct approaches to transform a collection into another. One is using higher-order functions like map() and another is using a loop and adding to a list. You use both of them at the same time. I think the following code should do exactly what you need (thanks #Joffrey for improving it):
val list = ids.map {
async(context) {
getResult(it)
}
}.awaitAll().filterNotNull()

Mono flatMap + switchIfEmpty Combo Operator?

Is there an operator that allows to process result/success whether or not Mono is empty. For example:
Mono<Bar> result = sourceMono.flatMap(n -> process(n)).switchIfEmpty(process(null));
where:
Mono<Bar> process(Foo in){
Optional<Foo> foo = Optional.ofNullable(in);
...
}
is there a shortcut operator that allows something like below or similar?
Mono<Bar> result = sourceMono.shortCut(process);
More specifically, mono.someOperator() returns Optional<Foo> which would contain null when Mono is empty and have value otherwise.
I wanted to avoid to create process method as mentioned above and just have a block of code but not sure which operator can help without duplicating block.
There is no built-in operator to do exactly what you want.
As a workaround, you can convert the Mono<Foo> to a Mono<Optional<Foo>> that emits an empty Optional<Foo> rather than completing empty, and then operate on the emitted Optional<Foo>.
For example:
Mono<Bar> result = fooMono // Mono<Foo>
.map(Optional::of) // Mono<Optional<Foo>> that can complete empty
.defaultIfEmpty(Optional.empty()) // Mono<Optional<Foo>> that emits an empty Optional<Foo> rather than completing empty
.flatMap(optionalFoo -> process(optionalFoo.orElse(null)));
As per above #phil's workaround, here is a reusable function:
private final <T> Mono<Optional<T>> afterSucess(Mono<T> source) {
return source
.map(Optional::of) //
.defaultIfEmpty(Optional.empty());
}
then invoke in publisher line:
Foo<Bar> result = fooMono
.transformDeferred(this::afterSucess)
.flatMap(optionalFoo -> process(optionalFoo.orElse(null)));

Clean code , testing and re-usability clarification

Aiming for clean code and testing . Each function / method , should do one and only one thing. this is the theory. to illustrate that i want to share with you some code and then question.
Let's say we need a method that will return a list of players if a condition is true and an empty list of the condition is false.
First approach: One method:
public List<int> ListOfPlayersIDs(int InputNumber)
{
if (Condition)
{
return new List<int>(new int[] {1, 2, 3}); // return a list with items
}
else
{
return new List<int>();//return an empty list
}
}
So here the method ListOfPlayersIDs performs two things:
returns a list of players
Verify if a condition is valid and returns an empty list if not
To divide those "functionality" we can have one method to check the condition and one to return the list of players.
Something like this:
Second approach: Two methods:
First Method
public bool ArePlayerValidForThisNumber(int InputNumber)
{
If (condition)
return true;
else return false;
//Or simply return condition;
}
Second method
public List<int> ListOfPlayersIDs(int InputNumber)
{
return new List<int>(new int[] {1, 2, 3}); // return a list with items
}
My question is :
Which approach do you follow and apply in your coding.
For me the second one is testable, reusable and each method does exactly what it suppose to do. but isn't just a theory in books? I read a lot of code and it does not respect this pattern.
What's your take on this?
It depends (tm). And it depends if you make your code cleaner and easier to understand when you break things into smaller methods.
Personally I would keep the external interface the same (the method can return a filled list or empty), as otherwise, if your client needs to do code if/else clause, you might be leaking logic. Also, I would use an approach called 'code at two levels of abstraction' or 'each method should descend one level of abstraction'. By doing this the final code might look like
public List<int> ListOfPlayersIDs(int InputNumber)
{
if (methodDescribingTheBusinessCondition()) {
return methodDescribingPositiveOutcome();
} else {
return methodNameDescribingNegativeOutcome();
}
}
The idea is that all of this should read like "normal" English, so someone reading the code will get the idea of what's going on without having to know all the nitty gritty details. Here each method is also doing just one thing and the method that orchestrates the whole thing is usually called a "policy" (as it describes your functionality).
If your method is simple, this level of abstraction might make it more difficult to understand.
Last but not least, this approach is explained in a few books (Clean Code to be very specific), and it's used as a good practice in professional development.

Chaining continuations together using .NET Reactive

Newbie Rx question. I want to write a method like the following:
public IObsevable<Unit> Save(object obj)
{
var saveFunc = Observable.FromAsyncPattern(...);
saveFunc(obj).Subscribe(result =>
{
Process(result);
return Observable.Return(new Unit());
});
}
The basic idea is: Save the given object, process the results in my "inner" continuation, then allow the caller's "outer" continuation to execute. In other words, I want to chain two continuations together so that the second one does not execute until the first one finishes.
Unfortunately, the code above does not compile because the inner continuation has to return void rather than an IObservable. Plus, of course, returning an observable Unit out of a lambda is not the same as returning it from the containing function, which is what I really need to do. How can I rewrite this code so that it returns the observable Unit correctly? Thanks.
Simplest solution is to use SelectMany
public IObsevable<Unit> Save(object obj)
{
var saveFunc = Observable.FromAsyncPattern(...);
return saveFunc(obj).SelectMany(result =>
{
Process(result);
return Observable.Return(new Unit());
});
}

Is it possible to continue with task C after A and B run to completion without fault or cancellation using a single TPL method?

I've tried to use Task.Factory.ContinueWhenAll() a few times now with the intent of invoking a continuation only when all the antecedents run to completion without any errors or cancellations. Doing so causes an ArgumentOutOfRangeException to be thrown with the message,
It is invalid to exclude specific continuation kinds for continuations off of multiple tasks. Parameter name: continuationOptions
For example, the code
var first = Task.Factory.StartNew<MyResult>(
DoSomething,
firstInfo,
tokenSource.Token);
var second = Task.Factory.StartNew<MyResult>(
DoSomethingElse,
mystate,
tokenSource.Token);
var third = Task.Factory.ContinueWhenAll(
new[] { first, second },
DoSomethingNowThatFirstAndSecondAreDone,
tokenSource.Token,
TaskContinuationOptions.OnlyOnRanToCompletion, // not allowed!
TaskScheduler.FromCurrentSynchronizationContext());
is not acceptable to the TPL. Is there a way to do something like this using some other TPL method?
There doesn't appear to be a direct way to do this. I've gotten around this by changing OnlyOnRanToCompletion to None and checking to see if Exception is non-null for each task passed into the continuation. Something like
private void DoSomethingNowThatFirstAndSecondAreDone(Task<MyResult>[] requestTasks)
{
if (requestTasks.Any(t => t.Exception != null))
return;
// otherwise proceed...
}
works, but this doesn't seem to be a very satisfying way to handle the case with multiple antecedents and breaks with the pattern the single-case Task.Factory.ContinueWith uses.