Hi Temporal team!
Temporal seems to perfectly match some of the use cases my team has and we’re looking forward to trying it in one of our projects. I have some questions I’d like to clarify before we dive in.
Our backend services are in Kotlin and we use Kotlin’s suspend (non-blocking) calls a lot, allowing us to run a lot of IO with a pretty small thread pool. We’re looking for ways to keep it that way when we’ll start using Temporal, especially when it comes to activities.
By default, activities occupy a thread the whole time they run, however, ActivityExecutionContext.doNotCompleteOnReturn()
seems to be the way to “non-blocking” activities.
- Is there any expected performance penalty for running (relatively short-lived) activities via
doNotCompleteOnReturn()
vs. regular blocking mode? - Can activity throw an exception after it calls
doNotCompleteOnReturn()
instead of returning an arbitrary return value? - Am I right that async activity can still heartbeat via
ActivityCompletionClient.heartbeat()
? - Do activities have some sort of lifecycle one could plug into? In particular, is there a way to plug into the shutdown of a particular activity or activity worker?
For background: I’m looking for a way to build a utility method that could look like this:
class MyActivityImpl(
private val activityCompletionClient: ActivityCompletionClient
) : MyActivity {
@Override
fun method(): String = asyncActivity(activityCompletionClient) {
// calls to non-blocking suspend methods
// at the end of this block activity will be resumed via ActivityCompletionClient
}
}
Another larger question - do you consider having something like Kotin SDK at some future point? One benefit I can see is that Kotlin SDK might probably build workflows as coroutines and suspend instead of blocking a thread, so a single worker might have hundreds of thousands or even millions of suspended workflows still stored in its cache, ready to respond to query or signal, and cache size could only be limited by JVM memory and not the thread pool size.