Question: Too many Session.Reset() calls

[TrayanZapryanov]

Hello,

I have a question about an internal class in
https://github.com/dotnet/corefx/blob/6977dddc03f8263ad82228558eb9b02e2e6f530c/src/System.Data.SqlClient/src/System/Data/SqlClient/SqlInternalConnectionTds.cs.
As shown in image below Session.Reset() call is one of main contributors to memory allocations:

I've tried to search over internet what can cause this class , but not luck.
Is it possible someone to say when public const byte FEATUREEXT_SRECOVERY = 0x01; was set as it obviously triggers
`if (_deltaDirty)
{

            _delta = new SessionStateRecord[_maxNumberOfSessionStates];
            _deltaDirty = false;

}` case.
Also is it possible to replace this array with a list as making 256 SessionStateRecord objects seems a bit too much for me.

[Wraith2]

If you can work up a small isolated reproduction (including any sql server setup) then i can investigate and might be able to make improvements. I haven't seen anything related to this while profiling other cases so it might be something specific on the sql side that triggers it.

[TrayanZapryanov]

Thank you for the check, but result is from a complex test and will be hard to isolate it. I hoped that somebody will remember what this "FEATUREEXT_SRECOVERY" means as it marks whole object as dirty.
If nobody have a clue, I will say that it is normal and will close the question.

[Wraith2]

I can tell you what it's for. It's a protocol feature for session recovery.

When enabled (which i don't know how you do at the moment) the server will occasionally send session state data to the client which stores that data. If the underlying TCP connection between them is disrupted the client can attempt to reconnect to the server and include the session data in the conneciton message, if the server finds an orphaned session with the same session identifier and state as the connection request it'll reconnect the two together and you carry on as if your connection hadn't dropped.

I had a brief look through the code last night and it does seem quite wasteful. In particular the new array allocation you point out might still work with just an Array.Clear() call. Without being able to enable the feature i'm a bit stuck for debugging options because i can't verify that i haven't broken anything.

[TrayanZapryanov]

Again thank you very much for the time spent on this issue and for the explanation. Captured memory profile was taken during a load test which creates a thousands of requests concurrently, some of which are executed in transaction which might be committed or rollbacked and after that retried. So it is really hard to isolate the problem. I guess this is mostly a test problem than something in reality. For the array clearing you are right that without a test is quite dangerous to touch it, also why it allocates 256 records instead of using an List<> is a mystery :).
I am gonna close this question for now until more data appears or it happens in production.