When controller is marked SessionStateBehavior.Disabled, Cache is accessed anyway

[ppsa-stephan]

I discovered this in my attempts to write code that handles cache failovers with some grace - as much grace as possible. The only way for me to simulate a cache failure/failover (for testing) is to reboot the cache while a client browser is attempting (in my case through AJAX calls) to access the app, and by extension, the session state.

My test case is a page that initiates two actions repeatedly, each of them one second apart, as AJAX calls. One of those actions is on a controller marked SessionStateBehavior.Readonly, and the other is on a controller marked SessionStateBehavior.Disabled. When the cache fails, I would expect the AJAX call on the "Readonly" controller to be affected, but would not expect the AJAX call on the "Disabled" controller to be affected.

Both AJAX calls typically take about 100ms to complete.

When the cache fails, I would expect the one on the SessionStateBehavior.Readonly controller to take considerably longer while the cache code itself attempts to retry, and then gives up. And in fact this is true - when the cache is in the middle of rebooting, that AJAX call (which ultimately fails) takes about 5 seconds to complete, and completes with a failure.

However, I would expect the one with the SessionStateBehavior.Disabled controller to operate without any delay and to succeed, since it doesn't need to access session state and and is marked that any access to session state would be illegal/violation of contract. And the good news is that it doesn't fail... it does succeed. But it takes it about 5 seconds to succeed, and from this I infer that it is also attempting (unnecessarily) to access the cache.

I would consider this a bug and that the code should be written so that when SessionStateBehavior is disabled, there is no attempt to access the cache.

[mapalan]

I can look into this issue. Would it be possible for you to share the test app? Apologies for the incredibly long response time, I'm relatively new and the rest of our team hasn't had time to update the repo in quite a while.

[ppsa-stephan]

Hi Maran, sorry I was offline for several days. I will look tomorrow (May 6) to see if I have this test app sitting somewhere easily accessible.

[ppsa-stephan]

Hi @mapalan - I have looked at my test code. It isn't easy for me to make it available without exposing confidential code. And the test isn't that graceful anyway. Would you like me to make a simple (but crude) test app with just this in it? Or is my initial description enough?

[mapalan]

I would prefer it if I had your test app also, so I can be certain that any changes actually fix the issue in a test app.

[ppsa-stephan]

Hi @mapalan - I have added a zip file that has the source code for a very crude test and a docx file with screen shots to tell you how to use it.

CacheSessionStateSample.zip

[mapalan]

Hi @ppsa-stephan, I wanted to give you an update on the situation. From trying to debug this issue, I found that the SessionStateModule is calling functions (eg GetItemExclusiveAsync) in the provider that require accessing session data and the cache even if the session state is disabled. I'll update you as I figure out more, but atm I've reached out to the owners of the SessionStateModule who might be able to help.

[ppsa-stephan]

Hi @mapalan - any news over the past month from the SessionStateModule owners?

[mapalan]

Sorry, unfortunately I don't have any updates :/
The team is aware of the issue and has said they'll will look into it, but they've had some other immediate high priority work, so it might take some more time

[DarthSonic]

Any news? How much time can it take to look into this issue further?

[ppsa-stephan]

Yes @DarthSonic ... seems that "the team" has no interest in this seemingly critical issue. Which is why I can't use the Cache in production. Sad.

[DarthSonic]

We are getting exceptions like "SetAndReleaseItemExclusive => System.NullReferenceException: Object reference not set to an instance of an object." for ActionMethods marked as SessionStateBehavior.Disabled very often, even if there is no single Session property or method called. And that is annoying. Removing the disabled state will slow down those methods.