Sitecore: content editor crashing randomly

3
votes

We have a problem whereby the content editor is crashing the browser (any browser - Chrome, Firefox & IE) and then seems to lock out the session.

This issue seems to happen in waves - for most of the day it works fine, then for a period of time it consistently happens. An example trigger point is selecting an item in the content tree, then clicking the edit button. The page then freezes. Sometimes it says 'Not Responding' in the title bar, but sometimes you can still click into the address bar, yet the page itself is completely non responsive, almost like there is an overlay over the page, preventing anything being clicked. If the address bar is still available to click, going back to root URL just causes the site to hang and just continuously loads.

What's interesting is that when this occurs, users can load up a different browser and login fine (with the same credentials). So the issue seems to be connected to the browser session. But if the user tries to perform same action (clicking the 'edit' button for an item) in the new browser then it crashes too.

I have checked the JavaScript console in the browsers development tools and there doesn't appear to be any JavaScript errors & there is nothing in the logs to suggest a problem so we are a bit confused.

We have around 6+ content editors working concurrently.

3
sitecoresitecore8.1
Any errors or jobs running logged in the sitecore log when this happens? - Adrian Iorgu
I would look at what customisations you have made in Sitecore, particularly item created and save actions. - jammykam
I don't have any customisations in the create/save pipelines. I have raised a ticket with Sitecore who want a Fiddler trace when the problem next occurs. So just waiting for it to happen again now - David Masters
I think you may need some performance tuning. 1. Try looking at [sitecore domain]/sitecore/admin/cache.aspx, and adjust values of data, items and prefetch caches so that they use less than 50% of what is assigned to them. 2. On items with list fields try to set data sources. 3. Change TreeList fields to TreeListEx fields. - Gabbar

3 Answers

3
votes

After sending a dotTrace sample to Sitecore support, they have confirmed there was a bug in version 8.1 that was causing this. The reference number for the bug is 92994.

As a work around, they suggested the following:

As a workaround for the issue, please set value of the Indexing.UpdateInterval setting to 00:00:00. It will disable automatic updates of Quick Search (aka system) search index. This search index is not used for searchin by Sitecore as Search.UseLegacySearchEngine setting is set to false. Thus, indexing can be safely disabled

Since applying this workaround, our users haven't reported the issue.

1
votes

Check to make sure you don't have a dependency hard-coded into your "Main Content" field that has been moved somewhere else in the content tree or deleted outright.

I've encountered this exact experience (freezing and then session lockout) when I moved a content item I had been linking to within an iframe. I had been using a hard-coded relative link and not a SiteCore link (otherwise, there would not have been an issue, since SiteCore auto updates internal links when content is moved).

The only solution I found with my particular issue was moving the updated content item back where it was, and then editing the "Main Content" field in the content item that referenced it (or restoring it to its original location, if it was deleted).

I realize your issue is not consistent, but it's worth checking out if you haven't already. If the changes that caused the freezing aren't yet posted to your staging or production environments, that could be why your users aren't seeing this happen constantly.

-1
votes

This happens on literally every Sitecore instance I've seen.

Sitecore uses synchronous requests in the admin interface - if you're looking in the browser console while in the admin interface you may notice that there's a stack of warnings about synchronous requests being deprecated because they may have a negative effect on user experience.

This negative effect is what you're experiencing, where the entire browser tab (or entire browser depending on which browser you're using) is locked and won't accept any input until the server responds.

Most of the time if you wait long enough (several minutes) the tab will become responsive again, but sometimes the server seems to just never respond and you just have to refresh the tab and find your place again.

To confirm that's what's happening when the browser is locked up, instead of looking for errors in the JavaScript console look in the Network tab of the developer tools for what request is taking a long time for the server to respond.