Sandbox Plugin Limits RRS feed

  • Question

  • I've read in other forum posts that sandbox plugins have a depth limit of 7 and an execution limit of 2 minutes.

    I'd like to know if that 2 minute limit is a per-plugin limit, or if it is the limit for the entire execution of a chain of async plugins (I would expect this to be the case with synchronous plugins, but I'm not clear on async plugins).

    For example, I have 2 async plugins on 2 different entities:

    Plugin A fires, does some work then updates another entity. Plugin A at this point has completed, and it took 1 min 30 seconds.

    Plugin B fires asynchronously due to the update done by Plugin A, depth is now increased by 1. Is its execution of Plugin B limited to 30 seconds or does its execution counter start at 0 again giving it 2 full minutes to execute?

    If the execution is limited to 30 seconds, is there a property on the PluginExecutionContext that I can look at to find out how much time the plugin has to execute?

    Also, when a plugin is killed due to taking too long to execute what kind of exception is thrown? And will I be able to catch this exception -- since handling the exception would mean the plugin is continuing to execute? I've seen an infinite loop error when the depth is exceeded, but do you get the same error when execution time is exceeded?

    Thursday, February 24, 2011 4:12 PM


All replies

  • Monday, February 28, 2011 6:55 PM
  • We're also running into this question and the link in the original answer doesn't seem to be accessible anymore. Is there any information on the depth limit of sandbox plugins and also how the timeout works across sync/async processes?
    Wednesday, June 29, 2011 6:36 PM
  • Unfortunately, those beta forums were shut down. Luckily for you I saved the response:

    There are several sources of Timeouts:
    • SQL Transaction Timeout: 2 Minutes
    • w3wp (IIS)/Asynchronous Service Connection to the Sandbox Service: 2 Minutes

    In the case of a synchronous plug-in, a SqlException will occur because the SQL Transaction will time out first (SQL transaction spans the entire pipeline from Pre-Operation to the Post-Operation stage and all plug-ins that execute). In the case of an asynchronous plug-in, the SQL transaction will most likely be the first to time out, but it may be the Sandbox connection; in that case, you'll see a TimeoutException. For asynchronous plug-ins, the Timeout is for a single asynchronous plug-in, not for all asynchronous plug-ins (or any synchronous plug-ins that already occurred).

    If a plug-in takes too long to execute, you won't be able to catch this exception. Consider the case where the SQL transaction times out during a Sandboxed plug-in's execution. Since the plug-in is not monitoring the SQL transaction, it will only be made aware of this when it tries to (1) make an SDK call or (2) returns back to the caller. This is normal behavior for most components when they timeout.

    In your example, Plug-in B would still have 2 minutes

    • Edited by jcaruso_fp Wednesday, June 29, 2011 6:42 PM formatting
    • Proposed as answer by Alon Havivi Thursday, October 3, 2013 10:40 AM
    Wednesday, June 29, 2011 6:41 PM
  • Thanks that is helpful. So no inherent depth limitations on the sandbox then when compared to non-isolatable?

    Wednesday, June 29, 2011 6:44 PM
  • From my experience, the depth limit is 7, regardless if you're working with sandbox or not, async or synchronous. And if you have a synchronous plugin calling an async or vice-versa, the depth limit is maintained.

    Wednesday, June 29, 2011 6:47 PM