https://kotlinlang.org logo
#spring
Title
# spring
s

sdeleuze

02/18/2019, 1:38 PM
g

gmariotti

02/19/2019, 10:44 AM
Hey, can I ask you a question? Is there any particular reason why you preferred
GlobalScope.mono
, for example in the WebClient? Isn’t there the risk that, if one of the
mono
fails, the
GlobalScope
will cancel all the others?
s

sdeleuze

02/20/2019, 9:35 AM
I am not yet a Coroutines guru, but I am not sure other will be cancelled with
GlobalScope
. Could you elaborate? Also see https://kotlinlang.slack.com/archives/C1CFAFJSK/p1548857935692300?thread_ts=1548856043.691400&cid=C1CFAFJSK.
It seems that our Reactive error handling will take care of managing the Coroutines created when using Spring API, this part is not using structured concurency on purpose, and I plane to use
Unconfined
dispatcher to be more efficient.
But on user side, that can integrate that in structured concurency in their code like I did in https://github.com/sdeleuze/spring-boot-coroutines-demo
But we could indeed maybe check in that demo application how things are going on in case of error or cancelation.
Feel free to fork this project and modify it to show me the problematic use case.
I have published that early to be able to have this kind of feedback 😉
g

gmariotti

02/20/2019, 9:42 AM
I’m handling the coroutines part for Vert.x and I was curious to see how Spring was going to integrate them. I’m still quite new to coroutines in general, that’s why I was curious about that decision. But if @elizarov says that, then I’m definitely wrong 😂
s

sdeleuze

02/20/2019, 10:22 AM
I will add integration tests to validate it works as expected for errors or cancellation.
e

elizarov

02/20/2019, 1:57 PM
Worry not.
GlobalScope
-launched coroutines will not be cancelled when one of them fails. They are not even referenced by the global scope. However, you indeed to have tests on the cancelation/failure scenarios to make sure nothing leaks and all the open resources are timely closed.
👍 3
s

sdeleuze

02/20/2019, 2:57 PM
@elizarov Thanks for your feedback. Regular exception handling seems to work fine, I get a 500 error and the exception is logged like with Reactive errors. But I am wondering if I should do something special about
CancellationException
. Currently if I throw a
CancellationException
from a suspendable request handler I get 500 error and the exception logged. That seems consistent with
GlobalScope.mono
documentation which mention "Failure with exception or unsubscribe | `error`". Is it what Kotlin users should expect or should
CancellationException
be handled as a special case on Spring side ?
e

elizarov

02/20/2019, 5:48 PM
On the surface it looks fine. However, we don’t usually log CancellationException in coroutines with a stacktrace, since that is supposed be part of normal, code-initiated cancel. But you might make a different choice in Spring. Please, check what you would see in logs when you handle timeouts via Reactor operators to make sure it is consistent.
s

sdeleuze

02/20/2019, 5:49 PM
Ok thanks
2 Views