Hi everyone!

We are using AWS DynamoDB Session State Provider ver 3.1.0.2. The provider is just used out of the box (added via NuGet, enabled via Web.config). Application server is Amazon EC2 instance.

From time to time (very rare) we observe request processing failures. The error log shows following stack trace:

[KeyNotFoundException: The given key was not present in the dictionary.]
   Amazon.DynamoDBv2.DocumentModel.Document.get_Item(String key) +86
   Amazon.SessionProvider.DynamoDBSessionStateStore.GetSessionStoreItem(Boolean lockRecord, HttpContext context, String sessionId, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags) +1171
   Amazon.SessionProvider.DynamoDBSessionStateStore.GetItem(HttpContext context, String sessionId, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags) +275
   System.Web.SessionState.SessionStateModule.GetSessionStateItem() +96
   System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData) +1053
   System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +12335126
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +288

We can't reproduce such failures. I've tried figure out the reason of such error and I found that session objects in the DynamoDB has following structure in all cases when such error occurs:

{
  "Expires": "2015-12-01T21:13:51.474Z",
  "Locked": 0,
  "SessionId": "zdzfgxacwkwdig0oopcnuxz3"
}

I've looked at sources of the GetSessionStoreItem method and assumed that either DateTime expire = (DateTime)session[ATTRIBUTE_EXPIRES] or session[ATTRIBUTE_LOCK_DATE] != null may cause such exception. So, I made manual changes in the session objects directly on the DynamoDB as follow:

{
  "Expires": "2015-12-01T21:13:51.474Z",
  "Locked": 0,
  "SessionId": "zdzfgxacwkwdig0oopcnuxz3",
  "LockDate": "2015-12-01T20:13:51.474Z"
}

And that resolved the issue. The subsequent request rewrite the session object as follow:

{
  "Expires": "2015-12-01T23:44:01.395Z",
  "LockDate": "2015-12-01T22:43:05.250Z",
  "Locked": 0,
  "LockId": "47741919-bde7-4450-8fc5-71f581964d66",
  "SessionId": "zdzfgxacwkwdig0oopcnuxz3"
}

Such fix has been applied multiple time and always solve the issue. What is still a question - why such situation occurs at all.

It would be nice if this provider created a TTL field in the DynamoDB record in the format that is required to set up TTL in DynamoDB. Then expired sessions could be deleted without implementing a scheduled cleanup function with DeleteExpiredSessions.

I am using custom session mode in asp.net MVC and set the timeout to 2 minutes. But after 2 minutes session is not expiring ?

<sessionState timeout="10" mode="Custom" customProvider="DynamoDBSessionStoreProvider" cookieless="false" regenerateExpiredSessionId="true"> <providers> <add name="DynamoDBSessionStoreProvider" type="Amazon.SessionProvider.DynamoDBSessionStateStore" Region="us-west-2" Application="--" Table="ASP.NET_SessionState" ReadCapacityUnits="3" WriteCapacityUnits="1" CreateIfNotExist="true" AWSAccessKey="--" AWSSecretKey="--" /> </providers> </sessionState> <authentication mode="Forms"> <forms loginUrl="~/Account/Login" defaultUrl="~/Home" timeout="10" slidingExpiration="false" /> </authentication>

How can I fix this issue ?

I'm sorry if this is the wrong place to ask about future work, but are there any plans to migrate this project to .NET Standard so that those of us using .NET Core can use this project?

Thank you!

Description

Please review this previous bug report: #5

The same behavior is happening but with the new latest version.

Since AWS SDK v.3.5.0.9 has been released I can't use latest version of AWS.SessionProvider anymore due to dependency conflict.

Environment

• OS Info: Windows 10
• Build Environment: Visual Studio Community Edition 2019
• Targeted .NET Platform:

• .Net 4.7.2
• AWS SDK for .NET: SessionProvider 3.3.0
• Dependencies: AWSSDK.DynamoDBv2 (>= 3.3.4 && < 3.4.0)

Reproduction Steps

• Go to the solution explorer
• Right-click on desired project
• Go to 'Manage Nuget Packages'
• Click on 'Update'

Logs

Unable to find a version of 'AWSSDK.DynamoDBv2' that is compatible with 'AWS.SessionProvider 3.3.0 constraint: AWSSDK.DynamoDBv2 (>= 3.3.4 && < 3.4.0)'.

Resolution

Does it compatible with Core v3.5.0.9? Could you update dependencies restrictions accordingly?

@PavelSafronov

Hello. I'm using the AWS.SessionProvider besides with many other libraries from AWS SDK for .Net.

Since AWS SDK v.3.3.0 has been released I can't use latest version of AWS.SessionProvider anymore due to dependency conflict.

AWS SDK for .NET: SessionProvider 3.1.0.2
Dependencies
AWSSDK.DynamoDBv2 (>= 3.1.0 && < 3.2.0)

Thus version of SessionProvider must be downgraded automaticaly down to

AWS SDK for .NET: SessionProvider... 2.3.52
Dependencies
AWSSDK (>= 2.3.52)

Does it compatible with Core v3.3.0? Could you update dependencies restrictions accordingly?

Hi there,

We are using AWS .NET SDK Session Provider and occasionally experience a problem that proceeds as follows:

1. Some part of the system causes a temporary slow down in response time
2. Users appear to hit F5 or trigger multiple AJAX requests or open windows in multiple tabs which cause multiple parallel requests. As the first slow request is holding a lock on the session, the multiple parallel requests are blocked during AcquireRequestState and are polling DynamoDB every 500ms - it appears from code inspection that each request would receive a Conditional Write Failure from DynamoDB on the first attempt, and then consume Read capacity on each successive poll.
3. Once enough users are in this state, we start to experience throttling - which we believe is happening at a partition/shard level (as we are scaled up to 300 read / 3000 write units for a short period during our peak period, our understanding is we may have 3 or more shards).
4. Our ops team manually increases dynamo provisioned throughput at this time, but it does not seem that any amount is enough to recover.

Once we hit stage four (which can happen within 15 minutes of the initial root cause) the only way we have found to recover is to kill all the instances in our ASG and let them start up again - it seems that some of them end up with background threads spinning and polling dynamo and consuming as much provisioned capacity as we can throw at it.

I have reviewed the source code in this repo, and it does not appear that anything in here is responsible for this, so it seems like an interaction effect between the default .NET Session Store logic (which controls the poll retry rate etc.) and the DynamoDB Session Provider's use of conditional failures to manage the locks.

So a few questions:

1. Has anyone else experienced anything like this?
2. Is anyone aware of what could be causing background threads to spin and poll Dynamo attempting to obtain the lock?
3. Does anybody with a more in-depth understanding of .NET Session Providers and the AWS DynamoDB Session provider in particular that might shed light on this problem?

This has caused too many incidents for us now and we are on the verge of abandoning DynamoDB as a session store, but I am really hoping a last ditch effort we can salvage it, as it does seem like a natural fit for the workload.

Thanks in advance,
Chris.

With the newly released option for setting DynamoDB read/write capacity to scale with demand - https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing - it will be awesome if this is updated to provide support for it. I can issue a PR for this bandwidth permitting.