Merge pull request #6734 from umbraco/v8/bugfix/6698-nucache-panic

Fixes nucache #6698
This commit is contained in:
Claus
2019-10-18 10:36:19 +02:00
committed by GitHub
3 changed files with 172 additions and 15 deletions

View File

@@ -1,4 +1,5 @@
using System;
using System.Diagnostics;
using Umbraco.Core.Models.PublishedContent;
using Umbraco.Web.PublishedCache.NuCache.DataSource;
@@ -6,6 +7,7 @@ namespace Umbraco.Web.PublishedCache.NuCache
{
// represents a content "node" ie a pair of draft + published versions
// internal, never exposed, to be accessed from ContentStore (only!)
[DebuggerDisplay("Id: {Id}, Path: {Path}")]
internal class ContentNode
{
// special ctor for root pseudo node

View File

@@ -549,7 +549,10 @@ namespace Umbraco.Web.PublishedCache.NuCache
// manage children
if (existing != null)
{
kit.Node.FirstChildContentId = existing.FirstChildContentId;
kit.Node.LastChildContentId = existing.LastChildContentId;
}
// set
SetValueLocked(_contentNodes, kit.Node.Id, kit.Node);
@@ -571,6 +574,7 @@ namespace Umbraco.Web.PublishedCache.NuCache
{
// replacing existing, handle siblings
kit.Node.NextSiblingContentId = existing.NextSiblingContentId;
kit.Node.PreviousSiblingContentId = existing.PreviousSiblingContentId;
}
_xmap[kit.Node.Uid] = kit.Node.Id;
@@ -729,7 +733,9 @@ namespace Umbraco.Web.PublishedCache.NuCache
// clear
if (existing != null)
{
//this zero's out the branch (recursively), if we're in a new gen this will add a NULL placeholder for the gen
ClearBranchLocked(existing);
//TODO: This removes the current GEN from the tree - do we really want to do that?
RemoveTreeNodeLocked(existing);
}
@@ -1002,9 +1008,9 @@ namespace Umbraco.Web.PublishedCache.NuCache
}
// else it's going somewhere in the middle,
// and this is bad, perfs-wise - we only do it when moving
// inserting in linked list is slow, optimizing would require trees
// but... that should not happen very often - and not on large amount of data
// TODO: There was a note about performance when this occurs and that this only happens when moving and not very often, but that is not true,
// this also happens anytime a middle node is unpublished or republished (which causes a branch update), i'm unsure if this has perf impacts,
// i think this used to but it doesn't seem bad anymore that I can see...
while (child.NextSiblingContentId > 0)
{
// get next child