Use an IBufferWriter<byte> to write the outgoing SSPI blob#2452
Use an IBufferWriter<byte> to write the outgoing SSPI blob#2452mdaigle merged 25 commits intodotnet:mainfrom
Conversation
This change removes the need to pre-allocate anything for the outgoing blobs of SSPI generation. As part of this: - An internal implementation of ArrayBufferWriter is added for platforms that do not support it - SqlObjectPool is imbued with the ability to create/reset pooled objects - TdsParser/TdsLogin is updated to use pooled ArrayBufferWriter instances to generate SSPI blobs - Native methods are updated to take in Span/* for writeable byte[] - SSPIContextProvider signature is updated to take IBufferWriter
|
@David-Engel can I get a review on this next step in the SSPI journey? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2452 +/- ##
==========================================
- Coverage 72.81% 66.19% -6.63%
==========================================
Files 282 277 -5
Lines 59112 58829 -283
==========================================
- Hits 43045 38944 -4101
- Misses 16067 19885 +3818
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@David-Engel ping |
|
I ran our internal Kerberos test pipeline against this PR and all tests passed. |
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SSPI/NegotiateSSPIContextProvider.cs
Outdated
Show resolved
Hide resolved
|
@David-Engel can you run this on the kerberos suite again? |
|
@David-Engel something is up with the merges so let me get those fixed before you do the kerberos runs |
|
@David-Engel I'm getting sporadic errors that don't seem to always repro: https://sqlclientdrivers.visualstudio.com/public/_build/results?buildId=96359&view=logs&j=b14281d2-3365-502e-c6c8-e9e46d660715&t=a67f9feb-8bad-50ac-92c7-d62292e3e6fb&l=63 Have you seen these or are they related to my pr? |
src/Microsoft.Data.SqlClient/netcore/src/Microsoft.Data.SqlClient.csproj
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/netfx/src/Microsoft.Data.SqlClient.csproj
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ArrayBufferWriter.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ArrayBufferWriter.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ArrayBufferWriter.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParser.cs
Outdated
Show resolved
Hide resolved
| { | ||
| internal partial class TdsParser | ||
| { | ||
| private static readonly SqlObjectPool<ArrayBufferWriter<byte>> _writers = new(20, () => new(), a => a.Clear()); |
There was a problem hiding this comment.
No complain here only I'm curious about the constant 20 pooled objects here!
cc @David-Engel
There was a problem hiding this comment.
honestly I don't remember where the 20 came from. Seemed reasonable I think at the time, but I'm not really aware of how many concurrent calls to it are called in a given connection
There was a problem hiding this comment.
I dug into the SqlObjectPool logic because I was curious, so thought I would share in case anyone else was wondering. 20 here isn't a limit on parallelism or anything. It's just the maximum number that will be cached. Parallel Rents from the pool above 20 will simply get a new object. I agree that 20 should be plenty for the majority of scenarios.
There was a problem hiding this comment.
Can you please add a comment in the code indicating the reasoning for 20?
This change removes the need to pre-allocate anything for the outgoing blobs of SSPI generation. As part of this:
Part of #2253