Will not start session state but works local

[TylerL]

The latest 330 update somehow is not starting session state. Any immediate ideas here? I'm having trouble finding basic troubleshooting information on this.

Error being thrown:

Soss.Client.StateServerException: I/O error occurred.
at Soss.Client.StateServerKey.AppNameToId(String appName, Boolean registerForEvents)
at Soss.Client.StateServerKey.get_AspSessionAppId()
at Soss.Client.SessionAccessor.CreateStateServerKey(String sessionId)
at Soss.Web.SossStoreProvider.CreateUninitializedItem(HttpContext context, String id, Int32 timeout)
at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Thanks,
Tyler

 

[markw]

Hi Tyler,
This is an unusual exception--it indicates that you're able to connect to the ScaleOut service but there's something wrong with the "application name" that's being sent to to the session provider. For session state, the application name is the path to your app in the IIS metabase--it usually looks something like "/LM/W3SVC/1/ROOT/MyAppName". Did you change the location or path to your application during the upgrade (possibly you're running against a different/test instance of your app now)?

A few questions:

• Is there any chance that the application name (as described above) exceeds 280 characters?
• It's possible to override the application name sent to the ScaleOut session provider by setting a soss_SharedAppName value in your web.config's <appSettings> section. Are you using this setting, and if so, does it exceed 280 characters or is it an empty (zero-length) string?
• The StateServerException that you pasted above has a StatusCode property on it. If you're able to view the exception in a debugger, what is the value of this code?
• On your web server, grant write permissions to your App Pool's account (i.e., "IIS AppPool\DefaultAppPool", or just "Everyone" if you're doing this temporarily) on the soss_tlog0.txt log file in the ScaleOut installation directory. Then restart the app pool, reproduce the error, and send the log to [email protected] (you should see some entries starting with "SOSS client lib: ..." in the log file after the permissions change).

 

[TylerL]

Mark,

Thank you for the response. I've sent this info to my guy working the problem. He has been contacted by support via email and is working the problem with them. I'll see if I can get more info on how we resolved this issue so others can see.

Thanks,
Tyler

 

[TylerL]

Just to keep all posted, this is what I have received from the team.

We experienced corruption in our Web Farm shared Cache deployment. After try many different in-line fixes, we go to destroy all object and rebuild.

Answer being destroy and rebuild, the team is working with Scaleout to determine root cause and not allow to occur again.

Thanks,
Tyler

 

[markw]

The issue is resolved--it was caused by an extra soss_client_params.txt file on the filesystem--it was getting picked up by client libraries during initialization and must have contained some old or invalid parameters (typically there should only be one copy of this file living in the product's installation directory). Version 5.8 had some changes made to how client applications search for this file, so it was now picking up this rogue copy, whereas version 5.7 had been ignoring it. Everything reportedly started to work as expected once the extra file was removed.