Hi all, I’m posting here for some feedback and rev...

# ktor

[Jacopo Franzoi]

Hi all, I’m posting here for some feedback and review.

Me and my team were working on a library for making long-running task executions on top of Ktor webapp. Here’s the result, I’m adding few more details in the thread, I’d be glad if anyone could provide some feedback. Thank you!

[Jacopo Franzoi]

Please, see Usage section for the proposed protocol (very basic HTTP stuff) and Caveats section, were we outlined our doubts about current implementation. Thanks again for any provided feedback 🙏

PS: I was doubtful since I was not able to find anything already done in the community, something similar to Spring’s @Async feature. For sure I was missing something 😂

[Matteo Mirk]

Cool name! 👍 😁

[Jacopo Franzoi]

Hello folks, don’t want to bother you too much, but here’s another attempt to get some feedback!

I was unclear so far, I’m posting to #ktor here (and probably posting to #coroutines as well) because we had to “work-around” a little the Ktor pipeline in order to make it work with coroutines later execution.

In particular, configuring DoubleReceive feature and warming up the applicationCall (so that body content was then available to later tasks execution - eg: receiveParameters() or receive<T>() for general parsing). And that was not deterministic, but only randomly happening (even in production-like envs), while never happening in dev env. That’s why we were guessing it’s a timing corner case. And we also weren’t able to unit test the background execution, since withTestApplication was always waiting for coroutines to be completed. Details available here.

Again, thanks a lot for any feedback on how to improve it (mainly, remove the additional DoubleReceive feature, if possible) and test it!