August Cumulative Update Causing Stack Overflows with DVWPs Running Over One Second
Today is one of those days where I try to figure out a bunch of odd situations in various places. The oddest was one involving a Data View Web Part (DVWP) I wrote about a year ago. It’s been running just fine ever since – until about a month or so ago. I didn’t hear about the issues until last week, and they didn’t make much sense to me.
Most of the time, the DVWP was loading just fine. Occasionally, rather than the spendiferous expected output (it really is a cool DVWP), users would see the wonderful error:
Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.
along with a correlation ID. Of course, that error can mean just about anything, as we DVWP lovers all know. The error is sporadic and there’s nothing obvious going on. No data or code has changed, so my theory was that there must be something going on with the server at the time of the error.
In looking at the logs, we saw that a stack overflow had occurred, but there wasn’t much else to go on. So why would the same code with the same underlying data sometimes cause a stack overflow and sometimes not? I looked through the code and didn’t see anything that I’d done which was dumb.
After going back and forth on this a bit, I remembered reading that there was a change in the August CU that set a limit on the amount of time that an XSL transform was allowed to take. As I understand it, it went from 5s in the June or July CU to 1s in the August CU. This can many times not be enough time if there is a server load. Ostensibly this is to protect against denial of service (DoS) attacks. And even better, if the 1s is exceeded, a stack overflow is forced even though there is no actual error. This means that if there is a server load, the DVWPs can be forced to a stack overflow needlessly. I’m piecing all of this together based on multiple blog posts and such, of course, so I’m not certain that it’s all correct.
With Glyn Clough’s (@glynclough) help
@sympmarc yep – we've run into a few issues with it. Here's a KB on workarounds: http://t.co/fCRCE85O
— Glyn Clough (@GlynClough) November 7, 2011
I was able to track down KB Article 2639184 which stated the problem, and gives some possible workarounds. I don’t find the workarounds to be all that palatable, though, especially the first one:
Simplify the custom XSL that was added to the DataForm web part.
If I could simplify the XSL, then wouldn’t I have done that when I wrote it to be efficient?
I’m hoping that there will be a longer term fix for this, ideally a way to set the 1s parameter to something more reasonable. I’ve emailed the MVP mailing list to see if there’s anything positive from the Product Team and I’ll update this post if I hear anything useful.
In the meantime, I’m not sure what we’ll do other than tell our users that they need to refresh any pages that have DVWPs on them until the error disappears. I’m sure that will make me popular.
In this thread, Dan Davis shows what he found when he used Reflector to look for what was causing the issue. Scroll down for Dan Davis’ post on Monday, September 19, 2011 at 8:47 PM.
<UPDATE dateTime=”2012-03-11″>
There is reportedly a fix for this in the February 2012 CU. See Fix in the February 2012 CU for Stack Overflows with DVWPs Running Over One Second Limit Imposed by the August 2011 CU.
</UPDATE>
Nice write-up Marc. I agree that this is a real pain. Whilst it’s perhaps understandable in the context of a public facing web site it’s something that should have an opt-out setting for scenarios where a slow transform is know, understood and accepted.
I’m hoping that this may come along in a future update – however the feedback that we’ve had is that the Product Team are aware of it, but that because it’s related to a security issue (DoS attacks) it’s not something that they’re looking to implement any changes to at this time. Hopefully my info is wrong on this though!
Another potential workaround that isn’t in the KB article is that an XSLT List View Web Part might be a possible replacement in some scenarios. In 2010 we have a great deal of control over the presentation with this and so a DVWP may not be required if it’s a simple list data source.
That said… I haven’t seen the stack overflow error with any of my XLVs – though as they ultimately inherit from the same data form web part as DVWPs then it’s possible that they have the same restriction anyway.
This is not understandable. This is a user experience issue and should be decided between devs and their customers. I don’t see any ASP.NET restrictions on page load times. Is SharePoint not a professional web application framework (on top of everything else it does)? Rather than imposing these limits, focus on making the DVWP implementation more efficient. I have received stack overflow exceptions when one of my templates in an XLV was too large, causing me to break it up into several smaller templates. I assume these are related?! If this was intentional, and they made a conscious decision to trade developer capabilities for a weak case about security, I am disappointed. It is not their place to decide what is an acceptable tradeoff in my situation, in my application, with my customers, my user base, and my IT/security policies. Frustrating…
Marc,
Thank you for reporting this! The link to the KB has been very helpful for explaining to customers. Do you know if this has been addressed?
Chris
Chris:
I haven’t been able to get any additional info that’s any more useful, unfortunately. Assuming that they did what we believe that they did, the only thing I know of that we can do is try to make our XSL as efficient as possible. Erg.
M.
p.s. In this thread, Don Davis shows what he found when he used Reflector to look for what was causing the issue:
http://social.technet.microsoft.com/Forums/sr-Latn-CS/sharepoint2010customization/thread/ad13e5e4-e211-453f-bfef-fe260591154a
Scroll down for Don Davis’ post on Monday, September 19, 2011 at 8:47 PM.
M.
The February 2012 CU adds an additional option.
https://blogs.msdn.com/b/joerg_sinemus/archive/2012/03/07/xslt-and-timeout-problem-when-transforming-runs-more-than-one-second.aspx
The following code lines will set the timeout to five seconds:
$farm = Get-SPFarm
$farm.XsltTransformTimeOut = 5
$farm.Update()
Anonymous:
That’s really good to hear. Another blog post on the way.
M.