Why do I get ErrorCode <ERRCA0022> when I take down one velocity cache host?

Question

I'm getting the following exception in my web app when I take down one node of a three node cluster which is hosting my users’ sessions.

The session cache also has secondaries on with no eviction.

Here is the error message and stack:

Exception information: 
    Exception type: DataCacheException 
    Exception message: ErrorCode<ERRCA0022>:Cache::GetAndLock: There is a temporary failure, please retry after some time. 

Stack trace:    at Microsoft.Data.Caching.DataCache.ExecuteAPI(RequestBody reqMsg, String apiName)
   at Microsoft.Data.Caching.DataCache.InternalGetAndLock(String key, TimeSpan timeout, DataCacheLockHandle& lockHandle, String region)
   at Microsoft.Data.Caching.DataCache.GetAndLock(String key, TimeSpan timeout, DataCacheLockHandle& lockHandle)
   at Microsoft.Data.Caching.DataCacheSessionStoreProvider.GetItemExclusive(HttpContext context, String id, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actions)
   at System.Web.SessionState.SessionStateModule.GetSessionStateItem()
   at System.Web.SessionState.SessionStateModule.PollLockedSessionCallback(Object state)

If I retry the request a few moments later the message will go away. Why am I getting this message in the first place and shouldn’t the server figure it out on its own that a host is down and switch to one of the other clients. I've defined the session client as simple in my web.config file just in case it was a routing problem but the issue still arises.

Answer 1

Hi, please refer to the following blogs:

http://blogs.msdn.com/velocity/archive/2009/04/30/the-dreaded-error-cache-get-the-request-timed-out.aspx http://blogs.msdn.com/velocity/archive/2009/06/17/troubleshooting-velocity-series.aspx

To answer your question about the server figuring out this on its own; it can actually do that, but since we cannot make a choice from the application developer's perspective (to retry or failfast), we leave it tothe application to employ the right behaviour for itself (retry, failing back to a DB, etc.). Hence we by default retry but we also having an aye on having some retry logic inbuilt if some application wants it. Hope this answers your query.