🧵 Performance & Threading model

[Spikhalskiy]

Description

Improve threading model in different areas of JavaSDK

Core Objectives

With the absence of coroutines, we create and use short-living separate Java threads for a lot of things.
This is wasteful and can be reworked to pooling, event loops, work-stealing, or any other solution that will minimize threads churning and also will allow management and constraining of resources used by a single workflow.

Workflow threads

• Support Workflow.getInfo from query method body #294
• @SignalMethod threading configuration #214
• Add workflowId to workflow thread name
• Cannot return value of WorkflowLocal var from query method #1120

Performance

• Implement Workflow Tasks backpressure for Pollers if there is no available executors #760
• Bring Pollers & Workers on par with Core and Go implementations #998
• Pollers should use just one thread to perform async gRPC requests #1456
• Don't perform a long poll of the execution result if nobody waits on it #343
• Deduplicate getResultAsync calls inside WorkflowClient or WorkflowStub #1413
• Implement autoscaling of Pollers #878
• Consider implementing a streaming interface on the server and SDKs instead of a long poll
• ServiceWorkflowHistoryIterator should eagerly request the next page #1707

Related user requests / reports

• MDC context logging properties not propagating inside promise.handle #1211