SharePoint Experts, Information Architects, Expert Witness

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: david_sterling@sterling-consulting.com or call 704-873-8846 x704.

Search This Blog

Wednesday, April 5, 2017

The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request

While I know Sandbox Solutions are going bye-bye, there are many on premise solutions where they are handy. However as some of you may have encountered, there are times when the error:

The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request

appears. There is a common post on this by Ricky Kirkham:

http://blogs.msdn.microsoft.com/sharepointdev/2011/02/08/error-the-sandboxed-code-execution-request-was-refused-because-the-sandboxed-code-host-service-was-too-busy-to-handle-the-request-ricky-kirkham/

Having encountered this issue recently, I tried following his instructions to no avail. None of the solutions there worked. However I did come across another one that did:

http://stackoverflow.com/questions/12293469/the-sandboxed-code-execution-request-was-refused-because-the-sandboxed-code-host

This solution is shown as follows:

$uc = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$uc.WorkerProcessExecutionTimeout = 5000
$uc.Update()
$tier = $uc.Tiers[""]   # default Tier has no Name
$tier.MaximumWorkerProcesses = 2    # number of CPU Cores + 1
$tier.Update()

By default, the Timeout is set to 30 and the Worker Processes set to 1. The above obviously changes 30 to 5000 (5000 seems a little excessive if you ask me) and the number of processes to be Cores + 1 (i.e. 4 Core Machine = 5).

This does indeed fix the problem! However, on my 8 Core machine, I thought that 9 was a bit much (might impact performance) so I set it at 2500/4 and it still worked.

To check your current settings, do the following in the Command Shell:

$uc = [Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$tier = $uc.Tiers[""]   # default Tier has no Name
$timeOut = $uc.WorkerProcessExecutionTimeout 
$timeOut
$mWProc = $tier.MaximumWorkerProcesses
$mWProc

FYI: If you apply changes you MUST Stop and Restart the Sandbox service through Central Admin - a reboot will also fix if you are not in production.

No comments: