[release/8.0] Removed unused sessions from SSL_CTX internal cache by github-actions[bot] · Pull Request #102095 · dotnet/runtime

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

github-actions · 2024-05-10T18:23:40Z

Backport of #101684 to release/8.0-staging

/cc @wfurt @rzikm

Customer Impact

Reported by customer via official support. Small repro available.
Customers on Linux sees increased memory usage when establishing parallel connections to the same host (note that parallel requests on HTTP/1.1 will always use parallel connections). Measured overhead can be easily 100M+, which is problem for containers in k8s clusters limited to 300M memory.

It also helped one customer in general "memory problems with .NET 6 -> 8 upgrade" issue - see comment.

Workaround is lowering TLS cache size via:

System.Net.Security.TlsCacheSize AppCtx switch, or
DOTNET_SYSTEM_NET_SECURITY_TLSCACHESIZE environment variable

Technical details:

The mechanism of the (bounded) memory leak is as follows:

On new TLS connection, we receive TLS session ticket so that future connections can use TLS Resume (for faster handshake) (this is new feature in .NET 7).
There are 2 TLS session caches: internal one in OpenSSL, and managed one in .NET. These caches are supposed to be in sync via callbacks (e.g. OpenSSL may remove an entry internally and notifies managed code via callback that a ticket has been invalidated).
When many connections are opened in a burst, we receive many TLS session tickets in quick succession, but the implementation keeps only the last one.
Sessions discarded from managed (.NET) TLS session cache were still being kept in the internal OpenSSL cache, until the ticket expired or the internal cache reached a predefined maximum size.

The fix is to keep the two caches in sync and remove the dropped TLS session tickets from the internal cache as well.

Regression

Yes, the bug is part of TLS Session resumption feature on Linux, introduced in .NET 7. For customers migrating from .NET 6 it manifests as E2E scenario regression.

Testing

Tested on customer provided minimal repro.
Customer was not willing to verify privates in production.
Note: Customer confirmed that the workaround helps them in production, which means we have high confidence, this fix is the real root cause of their production problems and will help them.

Risk

Low, the issue is well understood and the change is localized to the feature. Functional tests verified TLS resumption works.

This reverts commit 56a308e.

dotnet-policy-service · 2024-05-10T18:24:14Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

wfurt

LGTM

karelz · 2024-06-03T07:56:51Z

Memory usage impact on production systems. E2E scenario regression from .NET 6. We should service it.

rzikm · 2024-06-03T21:11:08Z

Approved via email on 06/03.

karelz · 2024-06-24T17:50:30Z

Will be part of July release 8.0.7.

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

rzikm added 3 commits May 10, 2024 18:23

Disable OpenSSL internal SSL_SESSION cache for clients
142621e

Attempt no. 2
148e7c9

Revert "Disable OpenSSL internal SSL_SESSION cache for clients"
338f1cd
This reverts commit 56a308e.

ghost added the area-System.Net.Security label May 10, 2024

rzikm requested review from karelz and wfurt May 13, 2024 08:09

rzikm changed the title ~~[release/8.0-staging] Removed unused sessions from SSL_CTX internal cache~~[release/8.0] Removed unused sessions from SSL_CTX internal cacheMay 13, 2024

wfurt approved these changes May 13, 2024
View reviewed changes

karelz added this to the 8.0.x milestone May 14, 2024

rzikm mentioned this pull request May 19, 2024
Large unmanaged memory growth (leak?) when upgrading from .NET 6 to 8 #95922
Closed

karelz approved these changes Jun 3, 2024
View reviewed changes

karelz added os-linux Linux OS (any supported distro) Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jun 3, 2024

rzikm merged commit bfaf24e into release/8.0-stagingJun 4, 2024

jkotas deleted the backport/pr-101684-to-release/8.0-staging branch June 7, 2024 03:26

karelz modified the milestones: 8.0.x, 8.0.7 Jun 25, 2024

github-actionsBot locked and limited conversation to collaborators Jul 25, 2024

Uh oh!

Conversation

github-actionsBot commented May 10, 2024• edited by karelz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Regression

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented May 10, 2024

Uh oh!

wfurt left a comment

Choose a reason for hiding this comment

Uh oh!

karelz commented Jun 3, 2024

Uh oh!

rzikm commented Jun 3, 2024

Uh oh!

karelz commented Jun 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

github-actionsBot commented May 10, 2024• edited by karelz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Regression

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented May 10, 2024

Uh oh!

wfurt left a comment

Choose a reason for hiding this comment

Uh oh!

karelz commented Jun 3, 2024

Uh oh!

rzikm commented Jun 3, 2024

Uh oh!

karelz commented Jun 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

github-actionsBot commented May 10, 2024• edited by karelz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Regression

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented May 10, 2024

Uh oh!

wfurt left a comment

Choose a reason for hiding this comment

Uh oh!

karelz commented Jun 3, 2024

Uh oh!

rzikm commented Jun 3, 2024

Uh oh!

karelz commented Jun 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

github-actionsBot commented May 10, 2024•
edited by karelz
Loading

github-actionsBot commented May 10, 2024•
edited by karelz
Loading

github-actionsBot commented May 10, 2024•
edited by karelz
Loading

github-actionsBot commented May 10, 2024•
edited by karelz
Loading

github-actionsBot commented May 10, 2024•
edited by karelz
Loading