We're getting an error out of the blue with our production 8.17.1 site. It gives a yellow screen of death with the following when trying to access any page or the backend:
Exception information:
Exception type: ArgumentOutOfRangeException
Exception message: Specified argument was out of the range of valid values.
Parameter name: handle
at CSharpTest.Net.IO.TransactedCompoundFile.Read(UInt32 handle)
at CSharpTest.Net.Storage.BTreeFileStoreV2.TryGetNode[TNode](IStorageHandle handleIn, TNode& node, ISerializer`1 serializer)
at CSharpTest.Net.Collections.BPlusTree`2.StorageCache.FetchFromStore`1.CreateValue(IStorageHandle key, Object& value)
at CSharpTest.Net.Collections.LurchTable`2.InternalInsert[T](Int32 hash, TKey key, Int32& added, T& value)
at CSharpTest.Net.Collections.LurchTable`2.Insert[T](TKey key, T& value)
at CSharpTest.Net.Collections.LurchTable`2.AddOrUpdate[T](TKey key, T& createOrUpdateValue)
at CSharpTest.Net.Collections.BPlusTree`2.StorageCache.TryGetNode[TNode](IStorageHandle handle, TNode& tnode, ISerializer`1 serializer)
at CSharpTest.Net.Collections.BPlusTree`2.NodeCacheNone.Lock(NodePin parent, LockType ltype, NodeHandle child)
at CSharpTest.Net.Collections.BPlusTree`2.Enumerator.SeekNext(NodePin thisLock, TKey key, NodePin& pin, Int32& offset, TKey& nextKey, Boolean& hasMore)
at CSharpTest.Net.Collections.BPlusTree`2.Enumerator.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__1.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.LoadEntitiesFromLocalDbLocked(Boolean onStartup, BPlusTree`2 localDb, ContentStore store, String entityType)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.LoadContentFromLocalDbLocked(Boolean onStartup)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.LockAndLoadContent(Func`2 action)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.<EnsureCaches>b__36_0()
at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory)
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.EnsureCaches()
at Umbraco.Web.PublishedCache.NuCache.PublishedSnapshotService.CreatePublishedSnapshot(String previewToken)
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at Umbraco.Web.UmbracoInjectedModule.EnsureHasContent(UmbracoContext context, HttpContextBase httpContext)
at Umbraco.Web.UmbracoInjectedModule.EnsureUmbracoRoutablePage(UmbracoContext context, HttpContextBase httpContext)
at Umbraco.Web.UmbracoInjectedModule.ProcessRequest(HttpContextBase httpContext)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
It seems to be difficult to find information about what causes this error and how to fix it. I've tried clearing the cache and TEMP directories, restarting the IIS site, and restarting the IIS server, ensuring that w3wp.exe isn't running, and various combinations thereof. I've confirmed from modification dates that nobody's messed around with bin or Web.config. I've checked the file permissions. The drives are nowhere near full.
Fixed. For reasons unknown, last night's SQL database backup is around 2.3x as big as normal. Restoring the previous night's backup has fixed the issue.
No idea what's wrong with DB at this stage or what caused the issue in the first place...
I wonder if it was to do with the maximum size of the nuCache file, as related to this issue? https://github.com/umbraco/Umbraco-CMS/issues/8447 Could explain why it happened when your DB got "bloated"?
Thanks. There seem to be a few reports of this issue floating around on GitHub and I'm not sure why I didn't see them when searching yesterday! I'll do some reading :)
Well, this hasn't happened again so far, and hopefully it'll stay that way. It seems that the bloated DB was the cause of the issue rather than a symptom, but I still have no idea what caused the bloat in the first place.
Guess what happened again. This site has been happily running without issue for literally years, and now it's failed twice in two months.
I noticed that NuCache.Content.db and NuCache.Media.db are both 256 MB, which I'm guessing isn't right!
Edit: It probably doesn't help that somebody's created a page with ~26 printed pages of text and images, with each image saved into the HTML in Base64. Sigh.
An older forum post but I wanted to say that Umbraco DOES NOT like base64 image data. Even if iis not that big saving it from a 3rd party service on one use case because the stupid 3rd party wont distribute just a URL for an image... It just has issues with cache building on such stored data.
I'm not sure why it even lets you save Base64 if it doesn't like it. I actually haven't seen the problem for some time, so it may have been fixed in a newer version of Umbraco (this particular site is on 13 now)... or maybe I've just been lucky.
No platform really.
Mine was not by choice.
The saving of that size data is just bad. Algolia for example wont let you send items with base64 data for an image even if its quite small. Rightly so.
The 3rd party solution we are interacting with I found that the base64 in some cases does out output correctly. Either as it saves to the database or through the custom API other developers made to produce an endpoint for the data it outputs incomplete/corrupted.
I was initially reading the data and making media items out of it to have an actual file but things were just going ape. Partly because of the size, partly because Umbraco caching was not happy and partly because some were incomplete.
If it is not icons where possible do not handle image blob data is a good rule of thumb.
ArgumentOutOfRangeException when site starts up
Hi,
We're getting an error out of the blue with our production 8.17.1 site. It gives a yellow screen of death with the following when trying to access any page or the backend:
It seems to be difficult to find information about what causes this error and how to fix it. I've tried clearing the cache and TEMP directories, restarting the IIS site, and restarting the IIS server, ensuring that w3wp.exe isn't running, and various combinations thereof. I've confirmed from modification dates that nobody's messed around with bin or Web.config. I've checked the file permissions. The drives are nowhere near full.
Any ideas?
Fixed. For reasons unknown, last night's SQL database backup is around 2.3x as big as normal. Restoring the previous night's backup has fixed the issue.
No idea what's wrong with DB at this stage or what caused the issue in the first place...
I wonder if it was to do with the maximum size of the nuCache file, as related to this issue? https://github.com/umbraco/Umbraco-CMS/issues/8447 Could explain why it happened when your DB got "bloated"?
Thanks. There seem to be a few reports of this issue floating around on GitHub and I'm not sure why I didn't see them when searching yesterday! I'll do some reading :)
Well, this hasn't happened again so far, and hopefully it'll stay that way. It seems that the bloated DB was the cause of the issue rather than a symptom, but I still have no idea what caused the bloat in the first place.
Fingers crossed that it never happens again!
Guess what happened again. This site has been happily running without issue for literally years, and now it's failed twice in two months.
I noticed that NuCache.Content.db and NuCache.Media.db are both 256 MB, which I'm guessing isn't right!
Edit: It probably doesn't help that somebody's created a page with ~26 printed pages of text and images, with each image saved into the HTML in Base64. Sigh.
An older forum post but I wanted to say that Umbraco DOES NOT like base64 image data. Even if iis not that big saving it from a 3rd party service on one use case because the stupid 3rd party wont distribute just a URL for an image... It just has issues with cache building on such stored data.
I'm not sure why it even lets you save Base64 if it doesn't like it. I actually haven't seen the problem for some time, so it may have been fixed in a newer version of Umbraco (this particular site is on 13 now)... or maybe I've just been lucky.
No platform really. Mine was not by choice. The saving of that size data is just bad. Algolia for example wont let you send items with base64 data for an image even if its quite small. Rightly so. The 3rd party solution we are interacting with I found that the base64 in some cases does out output correctly. Either as it saves to the database or through the custom API other developers made to produce an endpoint for the data it outputs incomplete/corrupted.
I was initially reading the data and making media items out of it to have an actual file but things were just going ape. Partly because of the size, partly because Umbraco caching was not happy and partly because some were incomplete.
If it is not icons where possible do not handle image blob data is a good rule of thumb.
is working on a reply...