I'm getting repeated exceptions thrown, and I'm trying to work out if this is a fault with Umbraco or not.
System.NullReferenceException: Object reference not set to an instance of an object.
at Umbraco.Core.Cache.HttpRequestAppCache.ExitWriteLock() in D:\a\1\s\src\Umbraco.Core\Cache\HttpRequestAppCache.cs:line 136
at Umbraco.Core.Cache.FastDictionaryAppCacheBase.ClearByKey(String keyStartsWith) in D:\a\1\s\src\Umbraco.Core\Cache\FastDictionaryAppCacheBase.cs:line 227
at Vendr.Core.Web.Cache.UmbracoAppCache.Set(String cacheKey, Object cacheValue)
at Vendr.Web.PropertyEditors.Stock.StockComponent.ContentService_Saving(IContentService sender, ContentSavingEventArgs e)
at Umbraco.Core.Events.TypedEventHandler`2.Invoke(TSender sender, TEventArgs e)
at Umbraco.Core.Events.QueuingEventDispatcherBase.DispatchCancelable[TSender,TArgs](TypedEventHandler`2 eventHandler, TSender sender, TArgs args, String eventName) in D:\a\1\s\src\Umbraco.Core\Events\QueuingEventDispatcherBase.cs:line 54
at Umbraco.Core.Services.Implement.ContentService.SaveAndPublish(IContent content, String culture, Int32 userId, Boolean raiseEvents) in D:\a\1\s\src\Umbraco.Core\Services\Implement\ContentService.cs:line 894
at Umbraco.Core.Services.Implement.ContentService.PerformScheduledPublishingRelease(DateTime date, List`1 results, EventMessages evtMsgs, Lazy`1 allLangs) in D:\a\1\s\src\Umbraco.Core\Services\Implement\ContentService.cs:line 1508
at Umbraco.Core.Services.Implement.ContentService.PerformScheduledPublish(DateTime date) in D:\a\1\s\src\Umbraco.Core\Services\Implement\ContentService.cs:line 1372
at Umbraco.Web.Scheduling.ScheduledPublishing.PerformRun() in D:\a\1\s\src\Umbraco.Web\Scheduling\ScheduledPublishing.cs:line 68
Do you think this is Vendr related? Vendr appears to be suffering from the issue, but I'm struggling to conclude if Vendr (v. 1.5.2) is the cause. I'm actually investigating the cause of Scheduled Publishing generally failing on the site.
Ahh, this might actually be because of something we are doing.
For the stock prop editor we have to update the value on content node during a save, which the best place to do this is in the Content Saving event as the node is still editable at that point, however we also can't do this until the content node has an ID and so we sometimes have to do it in the Content Saved event if the content is new. The problem with doing it in Content Saved though is that it's already persisted by then so we ultimately have to trigger a second save, which isn't ideal.
To try and keep things performant we end up performing the task in both Content Saving and Content Saved events and in the saving event, if we can do it there we set a flag in the request cache that it succeeded and so when we get to the Saved event, it knows not to bother trying a second time.
The problem though is whilst this will likely work for normal publishing, I'm guessing the fact the scheduled publish is a background task means there isn't a request cache available to store this flag, and so this must be why it's erroring.
I'll need to look at what we can do to flag this differently 🤔
Ok, so I should have a workaround for my particular issue, but there may actually be another which I don't think is my problem.
I've removed the use of a request cache and swapped it for a local memory cache instead so this is my problem solved, but I am seeing when a publish is triggered from a schedule there is a scope related error popping up to do with us calling _contentTypeService.Get("alias") in a handler which runs to format variant data in examine. From what I can tell, there isn't anything wrong we are doing, but the content type service isn't liking being accessed in a background task.
I've fixed this on our unstable feed that will make it's way into an 1.8.3 release. You're welcome to try the unstable build if you want to see if it solves your problem but it will require upgrading so you'll need to check the changelog.
Scheduled Published exception is Vendr related?
I'm getting repeated exceptions thrown, and I'm trying to work out if this is a fault with Umbraco or not.
I'm also getting a couple of warnings which could be related:
Do you think this is Vendr related? Vendr appears to be suffering from the issue, but I'm struggling to conclude if Vendr (v. 1.5.2) is the cause. I'm actually investigating the cause of Scheduled Publishing generally failing on the site.
Hi David,
Ahh, this might actually be because of something we are doing.
For the stock prop editor we have to update the value on content node during a save, which the best place to do this is in the Content Saving event as the node is still editable at that point, however we also can't do this until the content node has an ID and so we sometimes have to do it in the Content Saved event if the content is new. The problem with doing it in Content Saved though is that it's already persisted by then so we ultimately have to trigger a second save, which isn't ideal.
To try and keep things performant we end up performing the task in both Content Saving and Content Saved events and in the saving event, if we can do it there we set a flag in the request cache that it succeeded and so when we get to the Saved event, it knows not to bother trying a second time.
The problem though is whilst this will likely work for normal publishing, I'm guessing the fact the scheduled publish is a background task means there isn't a request cache available to store this flag, and so this must be why it's erroring.
I'll need to look at what we can do to flag this differently 🤔
Matt
Ok, so I should have a workaround for my particular issue, but there may actually be another which I don't think is my problem.
I've removed the use of a request cache and swapped it for a local memory cache instead so this is my problem solved, but I am seeing when a publish is triggered from a schedule there is a scope related error popping up to do with us calling
_contentTypeService.Get("alias")in a handler which runs to format variant data in examine. From what I can tell, there isn't anything wrong we are doing, but the content type service isn't liking being accessed in a background task.I've fixed this on our unstable feed that will make it's way into an 1.8.3 release. You're welcome to try the unstable build if you want to see if it solves your problem but it will require upgrading so you'll need to check the changelog.
Matt
Sorry for not getting back to you when you first responded. I did appreciate the quick response.
I'm hoping to try the unstable build later, and I'll confirm if this related to my issue.
is working on a reply...