You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in non-reactive programming, we could use synchronized or semaphore to guarantee only one thread enters some critical block.
e.g:
public synchronized fun() {
...
}
even though we already use the reactor, we still don't want the same user to call our service before the previous request is finished because some of our libraries aren't thread-safe.
but in reactor programming, we don't want to control that in the synchronized block or semaphore as those are blocking methods.
when mono1 and mono2 subscribe at the same time, they will subscribe first mono and only after the first mono is terminated, then subscribe second one. which is similar to controlled by Semaphore.
but implemented in a non-blocking way.
actually, I already implement that utility, but still wondering do you have any suggestions or a better way to solve this problem by native reactor library.
or if you are interested, I could share my utility later.
Considered alternatives
Additional context
The text was updated successfully, but these errors were encountered:
Motivation
in non-reactive programming, we could use synchronized or semaphore to guarantee only one thread enters some critical block.
e.g:
public synchronized fun() {
...
}
even though we already use the reactor, we still don't want the same user to call our service before the previous request is finished because some of our libraries aren't thread-safe.
but in reactor programming, we don't want to control that in the synchronized block or semaphore as those are blocking methods.
Desired solution
provide a simple utility like
when mono1 and mono2 subscribe at the same time, they will subscribe first mono and only after the first mono is terminated, then subscribe second one. which is similar to controlled by Semaphore.
but implemented in a non-blocking way.
actually, I already implement that utility, but still wondering do you have any suggestions or a better way to solve this problem by native reactor library.
or if you are interested, I could share my utility later.
Considered alternatives
Additional context
The text was updated successfully, but these errors were encountered: