From 4fd49f00f6c6708452efe3eaae74d5eb7587874a Mon Sep 17 00:00:00 2001 From: Dan Heath <76443935+Dan-Heath@users.noreply.github.com> Date: Thu, 30 May 2024 16:14:07 -0400 Subject: [PATCH] docs: Update release notes for 0.16.1 (#4838) * docs: Update release notes for 0.16.1 * docs: Specify fix is for self-managed versions * docs: Minor rewrites for clarity and style * docs: Minor rewrites for sentence length --- .../content/docs/release-notes/v0_16_0.mdx | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/website/content/docs/release-notes/v0_16_0.mdx b/website/content/docs/release-notes/v0_16_0.mdx index 071861aa1..bc1c478f9 100644 --- a/website/content/docs/release-notes/v0_16_0.mdx +++ b/website/content/docs/release-notes/v0_16_0.mdx @@ -144,5 +144,24 @@ description: |- + + + 0.16.0 +

+ (Fixed in 0.16.1 for Community and Enterprise editions) + + + Controller dead lock with database connections stuck in idle in transaction state + + + If you configured a controller to have the maximum number of open connections and it was under enough load from worker requests, the controller could get stuck. Once the controller consumed all the database connections, it would leave them in an idle in transaction state. In extreme cases, this could cause Boundary clusters to become unresponsive. +

+ The cause of this problem was due to a combination of issues. There was no request timeout for worker-to-controller GRPC requests. Also, the session repository attempted to use a separate database connection to retrieve a KMS wrapper after already starting a database transaction. +

+ This issue is fixed in release 0.16.1 for the Community and Enterprise editions. Boundary now sets a max request duration for GRPC requests based on the cluster's listener configuration. KMS operations now occur outside of the transaction. +

+ Upgrade to the latest version of Boundary + + \ No newline at end of file