Flooding the Sandbox

On March 19, 2012, in Insights, by John Underwood

In this blog post John Underwood, ThreeWill’s Technical Evangelist, talks about exceeding quotas in a Sandboxed Solution. Continue reading →

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:

A Web Part That's Guaranteed to Fail!

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:

Creating the Quota Template

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:

Selecting the Quota Template

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:

List Available Timer Jobs for Web Application

Using the output from the PowerShell script (and a few Google searches), I deduced that I needed the following jobs:

job-solution-resource-usage-log
job-solution-resource-usage-update

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.

Exceeding the Quotas and Updating the Results

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:

Daily Quota Exceeded

Upon returning to my page I get a different error message indicating that the daily quota has been exceeded:

Web Part Throws a Different Exception

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: