I only used

CoroutineRestOperations

from that lib and it doesn't require setuping a context so I don't really know. I suspect it's only syntax sugar but who knows ...

do you have any sample ?

Not really. I have converted all

@Async

with futures to coroutines a few days ago, and now stage environment times out

no issues locally

so I suspect threading and limited number of threads/slow CPU on stage

so you have something like this ?

fun fn() = async(ComonPool) { 
}

yes, something like that. And some nested async calls inside with awaits

but this returns deferred object. how do you get the value in controller then ?

yes, result.asCompletableFuture() and then do some magic to make it DeferredResult<MyResult>

ahhh ok

i don't see anything wrong with this approach 🙂

so the only problem might be CommonPool

try usin fixed size pool instead and check if this improves situation

I think problem occurs when man users talk to my backend, so concurrency is definitelly the issue

CommonPool

defaults to

(Runtime.getRuntime().availableProcessors() - 1).coerceAtLeast(1)

so you should have at least 1 thread but if you do not suspend too often then you will have problems

Everything in

async()

lambda is

suspend

, as far as I recall

maybe try asking on #coroutines channel too

hey @tjb I guess I ran into something similar because I didn’t have default values in my constructor

as listed in the note under https://kotlinlang.org/docs/reference/classes.html#constructors

hey @sauloaguiar glad you see you here 🙂 thanks! i changed it to a regular java-style class and it worked. i will refactor tomorrow to use `data class`es with a default value

😄 cool man! Let me know if it works for you as well

I believe if you call a blocking operation like RestTemplate then you'll still block the thread that the coroutines are running on effectively blocking all coroutines on that thread. The blocking operations would need their own thread pool. WebClient in Spring 5 should help with this since it's non-blocking.

@michael.barker yes, that kinda makes sense We have some legacy code with restTemplate, new backend is on Retrofit already I’ll make a new thread pool to replace CommonPool for such async operation, should help

although I can say that

async()

word is kinda confusing, if it’s not really meant for heavy async operations

Yes coroutines + Spring 5 WebFlux client + server may be a good fit see https://jira.spring.io/browse/SPR-15413?focusedCommentId=152431&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-152431

with the new functional bean definition are we able to get rid of opening our Kotlin classes?

just noticed that Spring is not moaning about it anymore. What are the caveats on final classes in these cases?

I believe it's still the same, but with using the kotlin compiler plugin, specific annotations (e.g, @Configuration, @Service) rewrite the class to be open.

I'm thinking of cases where we don't annotate our beans anymore but just register them using the functional API

Actually going through the example by sdeleuze seems that CGLIB is not in use at all anymore in those cases (Functional bean definition with Kotlin DSL (no reflection, no CGLIB proxies involved @ https://github.com/sdeleuze/spring-kotlin-functional)