Closed ModerModemet closed 4 years ago
Hi @Allemannen - that sounds pretty annoying! I'll check with the team if there's any obvious configurations that are missing or wrong. In the mean time, you write:
Sometimes some of the nodes retains the custom fields, while others not. Sometimes all nodes lose the custom fields.
Do you have logs from when some or all of the fields went missing? What does it mean they are missing, are they just not in the index (and how do you check this)? Is there a common theme to the missing fields, for example do they all store JSON data or something else maybe?
Hi @nul800sebastiaan - thank you very much for replying!
We inspect a node in the backoffice Examine Management, and all custom fields on that node are gone. In other words, the field value is not empty, the field simple doesn't exist. Though, the same field can exist on another node where the problem didn't occur, and either have a value or empty value depending on if there was any info that should be indexed. We've also built Examine search queries that rely on searching those custom fields, and those return no results on those nodes missing the custom fields. I havent used any other software to inspect the index.
Does Umbraco ensure that TransformingIndexValues events added via IUserComposer always have been attached before any form of automatic indexing occur on startup? Could it be the case that the programming logic executes kind of like a race condition, and everything works great until some other thread happens to be slower. Some things can be slower to initialize on Azure due to their infrastructure.
So far it has only occured once that all nodes lost all custom fields. The most frequent scenario is that only some nodes lose custom fields. When that happens, there seems indeed to be a pattern. All pages consist of 3 document types, where all pages of those 3 document types have lost their custom fields. Important to note is that I can't really determine if that is a true causation between cause and effect. It could just be that the pages with those 3 document types happens to arrive in a succesive order when the index job fetches all nodes to index, or some other obscure coincidence. Because I cannot for the life of me find any indication why those 3 document types should be different. I cant find that any of them has any unique property, or unique data to be indexed that the other document types don't have.
When looking through the log after I manual reindexed from backoffice Examine Management. Might not be important, because in this scenario everyhing always works as it should. I also remember when debugging that my breakpoint hit multiple times inside TransformingIndexValues for the same node, which I found strange. Just wanted to mention it because I'm desperately grasping for clues.
{"@t":"2019-08-14T06:02:01.9280522Z","@mt":"Rebuilding index '{IndexName}'","IndexName":"ExternalIndex","SourceContext":"Umbraco.Web.Editors.ExamineManagementController","ProcessId":12712,"ProcessName":"w3wp","ThreadId":27,"AppDomainId":2,"AppDomainAppId":"LMW3SVC857868861ROOT","MachineName":"RD0003FF76F2D4","Log4NetLevel":"INFO ","HttpRequestNumber":5,"HttpRequestId":"48154499-587c-4d9b-a109-cbe7e5c02d6b"}
{"@t":"2019-08-14T06:02:04.1039447Z","@mt":"Rebuilding index 'ExternalIndex' done, 122 items committed (can differ from the number of items in the index)","SourceContext":"Umbraco.Web.Editors.ExamineManagementController","ProcessId":12712,"ProcessName":"w3wp","ThreadId":38,"AppDomainId":2,"AppDomainAppId":"LMW3SVC857868861ROOT","MachineName":"RD0003FF76F2D4","Log4NetLevel":"INFO "}
{"@t":"2019-08-14T06:02:04.1039447Z","@mt":"Rebuilding index 'ExternalIndex' done, 122 items committed (can differ from the number of items in the index)","SourceContext":"Umbraco.Web.Editors.ExamineManagementController","ProcessId":12712,"ProcessName":"w3wp","ThreadId":44,"AppDomainId":2,"AppDomainAppId":"LMW3SVC857868861ROOT","MachineName":"RD0003FF76F2D4","Log4NetLevel":"INFO "}
{"@t":"2019-08-14T06:02:04.1039447Z","@mt":"Rebuilding index 'ExternalIndex' done, 122 items committed (can differ from the number of items in the index)","SourceContext":"Umbraco.Web.Editors.ExamineManagementController","ProcessId":12712,"ProcessName":"w3wp","ThreadId":30,"AppDomainId":2,"AppDomainAppId":"LMW3SVC857868861ROOT","MachineName":"RD0003FF76F2D4","Log4NetLevel":"INFO "}
It's hard to get log files, because the problem occur when I'm not actively using the site, since it has something to do when Azure server wakes up. Other people are visiting the site to test stuff, so it's hard to know if they previously have triggered the failure, and when that happened. I think the problem occurred in the log I attached in my first entry. I'll to try to reproduce the problem in a more controlled manner, to be sure to get 100% solid log.
After monitoring the site a couple of days its become clear that eventually after a couple of sleep/boot cycles all nodes lose their custom fields, even media (images, files).
Please is it possible to fix this in the source code?
Hi, I'd recommend updating to 8.1.2 there is a couple things in there that fixes/changes some Examine indexing issues, https://our.umbraco.com/download/releases//812
There was a timing issue which is fixed.
When using SyncTempEnvDirectoryFactory
, indexes should not 'just' rebuild out of nowhere because when using this setting the 'master' index files are located on the 'slow drive' in azure (over the network) and synced to the 'fast drive' (local to the server). But perhaps if you are slot swapping or something like that, then this could occur.
Rebuilding on startup when no indexes are found is performed on a background thread a few seconds after startup occurs, so in theory your even handlers should be bound before that occurs even before the fixes in 8.1.2.... but i guess stranger things have happened.
I'd recommend adding an info/debug log on your TransformingIndexValues call so that you definitely know it's executing and upgrading to 8.1.2 and see how you go. You should stick to using IUserComposer.
Yep i can replicate, i'll open a new issue for that. It's not causing any problems but should be reported correctly. The issue is that on an index rebuild we listen for the IndexOperationComplete
but then we populate the index based on all of the 'populators' which means that there a several index operations performed to rebuild an index.
We are experiencing exactly the same in our current Umbraco 8.6.2 website. So long after the 8.1.2 release... How is this possible?
We are simply adding custom field values for some mntps because of lucene queries we do based on that properties.
When for example doing a change in umbracosettings.config all of a sudden the custom fields are gone. After just doing a general search on our website the examine index is back the way it was (including the custom fields)
This is a really annoying bug that already has taken us days to debug without any success. Hopefuly there already is a solution for this?
@remkovb can you provide basic steps to replicate from a vanilla umbraco install?
@remkovb Do you have any custom indexes? Or have you customized the indexes? It sound like the same problem as here: https://github.com/umbraco/Umbraco-CMS/issues/8766
Steps to reproduce:
[RuntimeLevel(MinLevel = RuntimeLevel.Run)]
public class UmbracoCustomComposer : IUserComposer
{
public void Compose(Composition composition)
{
composition.Components().Append<RegisterExamineEventsComponent>();
}
}
Add component:
public class RegisterExamineEventsComponent : Umbraco.Core.Composing.IComponent
{
private readonly IExamineManager _examineManager;
private readonly IContentService _contentService;
public RegisterExamineEventsComponent(IExamineManager examineManager, IContentService contentService)
{
_examineManager = examineManager;
_contentService = contentService;
}
public void Initialize()
{
var externalIndex = _examineManager?.Indexes?.FirstOrDefault(f => f.Name == "ExternalIndex");
if (externalIndex != null)
{
((BaseIndexProvider)externalIndex).TransformingIndexValues += RegisterExamineEventsComponent_TransformingIndexValues;
}
}
private void RegisterExamineEventsComponent_TransformingIndexValues(object sender, IndexingItemEventArgs e)
{
int nodeId = e?.ValueSet?.Id?.To<int>() ?? 0;
IContent theNode = nodeId > 0 ? _contentService?.GetById(nodeId) : null;
if (theNode != null)
{
var themesValue = e.ValueSet.Values.Where(x => x.Key == "themes").Select(x => x.Value).FirstOrDefault();
if(themesValue != null)
{
var themesValueRewritten = themesValue.First().ToString().Replace(",", " ");
var themesList = new List<object>();
themesList.Add(themesValueRewritten);
e.ValueSet.Values.Add("__themes", themesList);
}
}
}
}
@remkovb Do you have any custom indexes? Or have you customized the indexes? It sound like the same problem as here: #8766
No just adding simple rewrite of mntp (comma to whitespace) on ExternalIndex
Update on my side... really strange behaviour, but maybe not for you guys..
The field seems to be there, but this query doesn't seem to give results, like I said: __themes:("umb document/a5eac17e7f9940d682d3a1b24ce88263")
But when we use this query, it gives results actually.. __themes:("a5eac17e7f9940d682d3a1b24ce88263")
So query on UDI seems to go wrong somehow?
Yes a query on UDI directly won't work because it contains a ":" which is a lucene char. To query a UDI it will need to be a custom analyzer/field type or it could be escaped. Understanding Lucene analyzers is important, depending on the one used will yield very different results, many special chars will be stripped out, etc... You can try to escape a UDI, this can be done with the Examine fluent API or if you are using NativeQuery then you need to use the lucene api to escape a string... but off the top of my head I'm not 100% that will work without a custom analyzer - for that field you could try using a whitespace analyzer and then escape the value.
But you still have a problem with disappearing custom fields when the app pool recycles, or..?
Well actually, by doing the queries and looking at fields in Examine tab I found out the field was actually there.
But somehow this: (generated with fluent api actually) __themes:("umb document/a5eac17e7f9940d682d3a1b24ce88263")
Normally works, but sometimes not, after reboot. When doing reindex of simply use search function on site the query above does return results.. Always use to query this way with udi's so don't really know why this is.
But after doing research, just using Key.Replace("-", "") always returns desired results, also after reboot: __themes:("a5eac17e7f9940d682d3a1b24ce88263")
So there is something in the background that makes udi's unsearchable after reboot or something? We now use the work-around to simply use Key as search argument. But still curious what's the cause ;-)
I've just done a few simple tests using your code and I can't reproduce the problem even after rebooting the site every way I can think of.
Here's my razor to do the query:
if (ExamineManager.Instance.TryGetIndex("ExternalIndex", out var index2))
{
var searcher = index2.GetSearcher();
var results = searcher.CreateQuery("content").Field("myThemes", "umb document/ca4249ed2b234337b52263cabe5587d1").Execute();
if (results.Any())
{
<h1>Results!</h1>
foreach (var r in results)
{
<p>@r.Id</p>
}
}
}
I have not use the ___
notation in my fieldname, that really should only be used for system fields as far as I know. My mntp values get converted correctly and stored in the myThemes
field and querying one works every time.
Mind you, I'm running on the 8.8 RC source code, but don't think anything has changed between 8.6.2 and 8.8.0. So maybe it's the underscores prefix?
If you can still reproduce then I recommend:
App_Code
:
using System.Collections.Generic;
using System.Linq;
using Examine;
using Examine.Providers;
using Umbraco.Core;
using Umbraco.Core.Composing;
using Umbraco.Core.Models;
using Umbraco.Core.Services;
namespace Testing
{
[RuntimeLevel(MinLevel = RuntimeLevel.Run)]
public class UmbracoCustomComposer : IUserComposer
{
public void Compose(Composition composition)
{
composition.Components().Append
public class RegisterExamineEventsComponent : Umbraco.Core.Composing.IComponent
{
private readonly IExamineManager _examineManager;
private readonly IContentService _contentService;
public RegisterExamineEventsComponent(IExamineManager examineManager, IContentService contentService)
{
_examineManager = examineManager;
_contentService = contentService;
}
public void Initialize()
{
var externalIndex = _examineManager?.Indexes?.FirstOrDefault(f => f.Name == "ExternalIndex");
if (externalIndex != null)
{
((BaseIndexProvider)externalIndex).TransformingIndexValues += RegisterExamineEventsComponent_TransformingIndexValues;
}
}
public void Terminate()
{
throw new System.NotImplementedException();
}
private void RegisterExamineEventsComponent_TransformingIndexValues(object sender, IndexingItemEventArgs e)
{
int nodeId = int.Parse(e.ValueSet.Id);
IContent theNode = nodeId > 0 ? _contentService?.GetById(nodeId) : null;
if (theNode != null)
{
var themesValue = e.ValueSet.Values.Where(x => x.Key == "themers").Select(x => x.Value).FirstOrDefault();
if(themesValue != null)
{
var themesValueRewritten = themesValue.First().ToString().Replace(",", " ");
var themesList = new List<object>();
themesList.Add(themesValueRewritten);
e.ValueSet.Values.Add("myThemes", themesList);
}
}
}
}
}
- Reproduce the problem
- If you can repro then zip the whole thing up and send it to us - including the username/pass to get into the backoffice please.
I'll close this issue for now since it's unfortunately not something that can be reproduced at the moment. Happy to have another look if you get it to fail on a clean install of course. Happy you have a workaround for now at least!
Thanks Sebastiaan and Shannon!
Great you guys are able to help me and look into this. Hopefuly I'll have the time to reproduce it next week. I'll let you know.
Please, can somebody help!
We're running Umbraco v8.1.1 deployed to an Azure Web App.
We're adding custom fields to the ExternalIndex by hooking up to the TransformingIndexValues event (code is shown further down).
After the site has been running for a while and server goes to sleep or some kind of swapping occurs (can't determine exactly what triggers it and don't know exactly how Azure works), Umbraco triggers a reindexing but not all nodes gets their custom fields added.
Sometimes some of the nodes retains the custom fields, while others not. Sometimes all nodes lose the custom fields.
When we publish nodes or trigger reindexing from the Examine Management in backoffice, custom fields are always added to all nodes.
Web.config
We've added two settings to the web.config under the \ tag:
Umbraco.Core.LocalTempStorage
\
Umbraco.Examine.LuceneDirectoryFactory
\<add key="Umbraco.Examine.LuceneDirectoryFactory" value="Examine.LuceneEngine.Directories.TempEnvDirectoryFactory,Examine"/ OR \
(we've tried both)
Composer and TransformingIndexValues
Composer RuntimeLevel
We've tried inheriting the Composer from ICoreComposer instead of IUserComposer to see if hooking up the the events earlier in the boot process makes any difference. Unfortunately, when using ICoreComposer the _examineManager.TryGetIndex("ExternalIndex", out IIndex index) fails to find ExternalIndex (fails on Azure, works locally). So this doesn't seem to be an option.
Log during boot and 30 min further on Azure