The operation failed because the server could not access the distributed cache, Sharepoint 2013

This is related to Sharepoint 2013 news feed. Most common  root cause;

  1. User Profile application pool account not having the full permission over User Profile Service Application.
  • One possiblity is User Profile application pool running account expiration.

Error Message:

SharePoint returned the following error: The operation failed because the server could not access the distributed cache. Internal type name: Microsoft.Office.Server.Microfeed.MicrofeedException. Internal error code: 55. Contact your system administrator for help in resolving this problem.

Refer this URL for microfeed “Internal error” codes, deciphered for any other error codes .

First go to the Centra Administration -> Userprofile service via browser and check the permissions. Then Open the IIS manager and go to the App pools. Identify the App pool account which is running the service applications.  Try re- enter credentials to verify that the account is not expired. If not compare the UPS permission list contains the app pool admin account or not. If not do 2nd step. or else try rebuild Distributed Cache and give permission again. (step 1 and 2 ).

Please Read my previos post to understand what is Distributed Cache.

1).

# Check  cache 
Use-CacheCluster
Get-CacheHost

# Rebuilding Distributed Cache
Remove-SPDistributedCacheServiceInstance
$SPFarm = Get-SPFarm
$cacheClusterName = “SPDistributedCacheCluster_” + $SPFarm.Id.ToString()
$cacheClusterManager = [Microsoft.SharePoint.DistributedCaching.Utilities.SPDistributedCacheClusterInfoManager]::Local
$cacheClusterInfo = $cacheClusterManager.GetSPDistributedCacheClusterInfo($cacheClusterName);
$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
$serviceInstance = Get-SPServiceInstance | ? {($_.Service.Tostring()) -eq $instanceName -and ($_.Server.Name) -eq $env:computername}
$serviceInstance.Delete()
Add-SPDistributedCacheServiceInstance

Get-CacheHost

 

2).

#Grant permission to UP app pool account to access UPS

$account = New-SPClaimsPrincipal <domain>\<username> -IdentityType WindowsSamAccountName
$UPA = Get-SPServiceApplication <UPS App ID>
$sec = Get-SPServiceApplicationSecurity $UPA
Grant-SPObjectSecurity $sec -Principal $account -Rights “Full Control”
Set-SPServiceApplicationSecurity -Identity $UPA -ObjectSecurity $sec

You can achive the same by using Central administration -> Manage services -> User Profile Service -> Permission (Grant full control )

 

Advertisements

what is parallel execution in PLINQ ?

I got this  blog once i was surfing the internet for new features in .NET 4.5. This is something interesting about PLINQ queries and its behaviours. As the title says “it’s not always guaranteed that your query is always executed parallelly”.

Yes, You may think that AsParallel() method runs in parallel for query with much faster and with increased performances.  By default, PLINQ prefers to use a simple sequential algorithm over a potentially expensive parallel algorithm, and so some queries will execute sequentially, especially queries where the chain of operators do not lend themselves to parallelism. PLINQ’s intent is to run your queries as fast as possible, so if there’s a good likelihood that the complexities of parallelism will slow it down, PLINQ will perform the query sequentially rather than in parallel.

In .NET 4.5, PLINQ’s algorithms have improved over .NET 4.0 such that its set of parallelizable queries has broadened and substantially fewer queries fall back to sequential execution.  In .NET 4.0, in order to force PLINQ to use a parallel algorithm, user can call;

WithExecutionMode(ParallelExecutionMode.ForceParallelism);

But in .NET 4.5 the query executes is in parallel, even without the WithExecutionMode hint.

Sequential Fallback in .NET 4 and .NET 4.5

One way to illustrate the improvements to the sequential fallback is to look at the list of operators that may cause the query to fallback to sequential. Whether or not the operator actually causes a sequential fallback depends on other operators in the query as well.

Operators that may cause sequential fallback in both .NET 4 and .NET 4.5 are marked in blue, and operators that may cause fallback in .NET 4 but no longer in .NET 4.5 are marked in orange.

PLINQ

So, in .NET 4.5, as long as the query does not contain positional operators or the ElementAt operator, it will not fall back to sequential.

Potential Risks of the Change

The fact that some queries used to execute sequentially and now execute in parallel opens up the possibility of exposing more latent race conditions in users’ code.

There is a bug in the query above: the delegate passed into the Select operator is not thread-safe. However, the query will still happen to work in .NET 4, because as an implementation detail PLINQ decides to execute the query sequentially. In .NET 4.5, the query will run in parallel, and so list.Add(x) could be called from multiple threads concurrently, potentially resulting in a corrupted List instance.

Please refer the original Post by gor Ostrovsky – MSFT here.