[SslStream] Dispose seems to call blocking IO

[ManickaP]

In particular that it looks like blocking I/O is happening as part of that cleanup. That’s also something we should strive to avoid.

We should investigate and see if we can get rid of the blocking IO.

Discovered during investigation of the same problem as #61505

cc: @stephentoub @wfurt

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

In particular that it looks like blocking I/O is happening as part of that cleanup. That’s also something we should strive to avoid.

We should investigate and see if we can get rid of the blocking IO.

Discovered during investigation of the same problem as #61505

cc: @stephentoub @wfurt

Author:	ManickaP
Assignees:	-
Labels:	bug, area-System.Net.Security, untriaged
Milestone:	-

[geoffkizer]

We should investigate and see if we can get rid of the blocking IO.

I don't think we can get rid of the blocking IO here since it's just an LRPC call deep in the SCHANNEL code.

I think what we care about here is ensuring that these calls (i.e. calling Dispose on the connection's stream, which is calling SslStream.Close in this case) are not blocking any important processing or cleanup that should be occurring.

The code is already structured to gather up all the connections to dispose and then dispose them outside of the connection pool lock, so we are not holding any locks here that would prevent someone from using the connection pool, which is good.

However, we are blocking RemoveStalePools() from being able to continue scavenging other connection pools until these connections get disposed.

I would suggest we just spawn a background Task to actually dispose the connections and then return back to RemoveStalePools without waiting for it to complete. This should allow RemoveStalePools to make progress more quickly, and hopefully result in better scavenging of pools and connections overall.

[geoffkizer]

BTW, this seems like a good thing to do regardless of blocking or not. Even for non-SSL cases, NetworkStream.Dispose will require a kernel call and that's never cheap.

[karelz]

It was fixed in main (7.0.0) in PR #61530

[stephentoub]

I don't think we can get rid of the blocking IO here since it's just an LRPC call deep in the SCHANNEL code.

Can we validate there's no other option, no way to achieve this asynchronously? Some other API we should be calling, or some other option we can set, or some such thing? It's good that it's now not blocking cleaning up other connections in the cleanup loop, but it's still blocking a thread pool thread.

[wfurt]

I don't think we can get rid of the blocking IO here since it's just an LRPC call deep in the SCHANNEL code.

Can we validate there's no other option, no way to achieve this asynchronously? Some other API we should be calling, or some other option we can set, or some such thing? It's good that it's now not blocking cleaning up other connections in the cleanup loop, but it's still blocking a thread pool thread.

I can take a look but AFAIK all the APIs are synchronous. The fact that it happens in different process are completely opaque to caller.

[karelz]

Fixed in main (7.0) in PR #61530 and in 6.0.2 in PR #62008.