docs/release_notes/v1.15.6.md
This update includes bug fixes:
Running Actor or Workflow workloads would see the daprd process consume more and more memory over time.
Running Actor or Workflow for long enough periods of time would see the daprd process consume all available memory, leading to an OOM crash.
The Actor locking mechanism would not release object memory after use, in the case where the daprd it calling a remote Actor.
Defer Actor message locking to only the daprd which is hosting that Actor ID to ensure the lock object memory is always released after use.
Running Workflows in high throughput scenarios would see contention on processing or blocking Workflow state store operations.
Degraded performance of Workflow operations, leading to increased latency and potential timeouts.
Circular Placement locking of Actor Workflow state operations.
Remove Placement locking in Workflow state operations as it is already locked at the Actor level.
Workflows would experience degraded performance in high throughput scenarios.
Workflows would be limited in the number of concurrent operations they could handle, leading to increased latency and potential timeouts.
The default value for maxConcurrentWorkflowInvocations and maxConcurrentActivityInvocations was set to 1000, which could lead to performance issues in high throughput scenarios.
Increase the default value for maxConcurrentWorkflowInvocations and maxConcurrentActivityInvocations to max int32 value, allowing for more concurrent operations to be processed without contention.
The injector was using a client-side rate limiter that could cause throttling issues in production environments with high-throughput scenarios.
Degraded performance and potential service disruptions when the injector was under heavy load.
The client-side rate limiter in the injector was unnecessarily restricting operations, causing bottlenecks in high-traffic scenarios.
Remove the client-side rate limiter from the injector to allow for better performance and eliminate unnecessary throttling in production environments.
Attempting to schedule a Workflow on a daprd with no Workflow listener stream would hang.
Attempting to schedule a Workflow on a daprd with no Workflow listener stream would hang indefinitely.
The daprd would wait until a Workflow listener stream was established before processing the schedule request.
Allow scheduling of Workflows without requiring a Workflow listener stream to be established first. This allows for immediate processing of the schedule request.
Daprd would fail to find the Placement leader host.
Actors (or Workflows) would fail to continue to function.
The daprd DNS record set used to round robin the Placement hosts would not be refreshed in the event the leader host was shutdown.
Add a retry mechanism to the daprd to refresh the DNS record set for the Placement hosts, ensuring that it can always find the current leader host even during leader shutdown events.
Connecting a Workflow stream when there is worked queued in the system would cause a large number errors.
Connecting a Workflow stream when there is work queued in the system would cause a large number of errors, leading to degraded performance and potential timeouts on existing Workflows.
Daprd would connect to Scheduler to receive Workflow work before Placement had disseminated.
Ensure that the daprd connects to the Scheduler only after Placement has disseminated, preventing errors and ensuring that the daprd is ready to process Workflow work without contention.
Under high load, like with high Workflow through put, a Scheduler would deadlock.
Workflows and the Jobs API would fail to trigger.
The Scheduler would not retry or handle transient Etcd errors related to high contention.
Add retry logic to the Scheduler to handle transient Etcd errors, preventing deadlocks and ensuring that Workflows and Jobs can be triggered successfully under high load conditions.