As you work with and develop sandboxed solutions, you may find the need to intentionally exceed a solution’s quota for testing or demonstration purposes. Here’s a little insight on a demo I recently created that does that very thing.
Rewarded For Doing the Wrong Thing?
Usually developers don’t get rewarded for writing code that blows up, but in this case that’s precisely what I wanted to do. I wanted to create a simple sandboxed solution that could easily and predictably exceed a resource quota so that I could demonstrate what happens when an errant sandboxed solution gets “locked up” for the day. To accomplish this, I created an Empty SharePoint Project using Visual Studio 2010, and then I wrote a simple web part (not a visual web part, mind you) that would throw an exception in its OnLoad() method as follows:
From there, I deployed the solution to the site, created a new page in the Site Pages library, and added my web part to the page. Obviously, from this point forward any time the page loads, the web part will generate an unhandled exception.
Setting The Bar Low
Next, I set artificially low quotas so that I could reach my quota limit very quickly. This involved the following steps:
- Navigate to Central Administration | Application Management | Specify quota templates
- Create a new template named “Small Sandbox” with the following settings:
- Click OK to save changes.
Once the quota template is created, we’ll need to use it:
- Navigate to Central Administration | Application Management | Configure quotas and locks
- Select the correct web application and then apply the previously created template as follows:
- Click OK to save changes.
It’s All in the Timing
Now that we’ve configured the quota limit at a single point, one would assume that we could simply request the page with the errant web part a sufficient number of times and immediately exceed the quota. However, there’s one problem: the statistics used to measure quotas do not update instantly, but instead wait on the following timer jobs:
- Solution Resource Usage Log Processing (runs every 5 minutes by default)
- Solution Resource Usage Update (runs every 15 minutes by default)
In order to actually get to the point where I’d exceed the daily quota I could have done any of the following:
- Sit around and wait on the timer jobs (boring, and a time-waster)
- Interactively choose to run the jobs from Central Administration (useful, but a bit tedious after a while)
- Run them from PowerShell (yes!)
Now, if the timer job is named “Solution Resource Usage Log Processing” then one would assume that’s the name we’d use in PowerShell, amirite? Well, not so fast… there’s a completely different name that must be used from PowerShell and, as far as I can tell, these alternate names aren’t documented on the Microsoft site (if anyone does have a link, I’ll take it). So, I used the following PowerShell script to list all of the timer jobs for my web application:
Using the output from the PowerShell script (and a few Google searches), I deduced that I needed the following jobs:
The completed PowerShell script exercises the errant web part by repeatedly requesting the page that hosts it, and then kicks off the correct time jobs. Remember, the PowerShell script simply kicks off the jobs – it doesn’t wait until they finish! Because of this there still might be a short lag time between the running of the job and the updating of the statistics.
All Locked Up
To show the current quota usage, do the following:
- Click Site Actions | Site Settings
- On the Site Settings page click Solutions (in the Galleries section)
Once the quota is exceeded the following information is presented:
Upon returning to my page I get a different error message indicating that the daily quota has been exceeded:
Hitting the Reset Button
Presumably, one would want to be able to reset the quota once the demo or test was complete. Again, the key lies with a timer job. In this case it is the “Solution Daily Resource Usage Update” job that resets the daily quota count back to zero. Using the name “job-solution-daily-resource-usage” I was able to kick off the timer job from PowerShell as follows:
Other Ways to Fail
If you wish to stress test other aspects of the quota points calculation, the following articles may be of interest:
- Resource Usage Limits on Sandboxed Solutions in SharePoint 2010
- Configure resource points for sandboxed solutions (SharePoint Server 2010)