2

The title says it all... I am trying to programmatically activate some sandbox features (from within a feature reciver that is also part of the sandbox solution). And whilst the features without receivers all activate fine, those with receivers fail with the following exception:

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

To reiterate, this only happens for custom sandbox features which have feature receivers attached -- even if the feature receivers are completely empty.

Does anyone know why this is occurring? And if so, how I can work around it?

FYI #1: For anyone trying to replicate this, you need to use the following overload (passing in SPFeatureDefinitionScope.Site) to programmatically activate a feature from a sandbox solution:

SPFeatureCollection.Add Method (Guid, Boolean, SPFeatureDefinitionScope)

FYI #2: This same error message also appear misleadingly in a number of other situations. None of the issues addressed here seem to solve my issue.

FYI #3: Perhaps this blog post is related to my issue though?

UPDATE #1: I am able to successfully activate all of my sandbox features (which have receivers) via the UI.

UPDATE #2: I am also able to successfully activate all of my sandbox features programmatically from a within farm feature's receiver.

UPDATE #3: I am not able to programmatically activate my sandbox features using the SharePoint client object model as the Micrsoft.SharePoint.Client.dll assembly cannot be called from within the sandbox (from partially trusted callers).

Improve this question
4
  • Where are you uploading your solution? Is it on a On-Premise SP Environment or on Office 365?
    – Vardhaman Deshpande
    Aug 6, 2012 at 18:37
  • Also, if you activate the features (with the event receiver attached) manually through the UI, do they get activated?
    – Vardhaman Deshpande
    Aug 6, 2012 at 18:44
  • My solution is currently deployed to a local (on-premise) SharePoint instance for development purposes, but it'll be deployed to SharePoint Online in production. Also, the features with receivers all activate fine when activated individually via the UI -- the exception only occurrs when I try to activate them programmatically inside another feature receiver (i.e. I have one feature which activates a bunch of others, acting like a site definition).
    – user4545
    Aug 7, 2012 at 3:21
  • Yes I have faced this same issue and could not manage to find a solution until now. I think this a limitation in Sandbox solutions. In my case, I had the features declared in a WebTemplate. And only the features who did not have event receivers would get activated when a site was created from that WebTemplate.
    – Vardhaman Deshpande
    Aug 9, 2012 at 17:33

3 Answers 3

Reset to default
1

This was one of the problem we faced when we were developing appilication for office 365 where it came up with error The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request. what we concluded was that the server was being kept busy for too long what it means was we had a code portion where the fetching up for data from the lists and that data being used very frequently was what was creating this. for example we were fetching listitems once then doing operations then passing the operated values to a different method then using it again. This hit the server badly hence the error. what we did was reduce the no. of fetchin of data and server hits. which ultimately helped.

I hope this helps.

Improve this answer
1
  • Thanks for your insights @Sreejit. All I'm doing is programmatically activating OOTB features though, so there's not much I can do about reducing the load on the CPU. For the record, I'm still searching for an answer on this...
    – user4545
    Aug 21, 2012 at 2:21
1

For anyone experiencing this same problem, we never were able to resolve this issue and so eventually veered away from the programmatic activation of features approach. Instead, we created a series of custom web templates and simply listed all the features (OOTB and custom) in the schema.xml file which are to be turned on as part of that site's initial setup. This is a much neater solution and also supports other features such as being able to pass XML properties to your custom features.

Improve this answer
0

This same issue just popped up again -- but on a different farm this time. This time however, it was occurring every time I tried to provision a new site using one of my custom web template's. This was odd, since activating features with receivers via the onet.xml wasn't causing me any grief before. It could be because I'm now on SharePoint 2013 now, but who knows.

Anyway, for reasons I can't quite explain, flushing the blob cache via PowerShell just fixed the issue for me, see instructions below:

http://technet.microsoft.com/en-us/library/gg277249.aspx

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.