Could it be this? http://issues.umbraco.org/issue/U4-6338

We've had issues with indexes locking which then get out of sync / corrupted requiring app pool to be stopped to free up the lock and reindex. Applying the hot fix mentioned in that issue seems to have resolved it for us so far.

Matt

Matt,

Site is on azure so not sure if this applies?

Regards

Ismail

Hi Ismail,

We had some issues with examine as well on a azure web app and noticed also performance issues accessing examine.

After changing some configuration our problems were solved

Apply the settings on this page under Common load balancing setup : https://our.umbraco.org/documentation/Getting-Started/Setup/Server-Setup/load-balancing/

Then apply the settings described here : https://our.umbraco.org/documentation/Getting-Started/Setup/Server-Setup/load-balancing/flexible

Dave

Dave,

Will take a look however we are not load balancing

Regards

Ismail

Hi Ismail,

We only have one web app for the moment and these config changes made a drastic impact on performance.

Dave

Hi Ismail,

Are your logs showing errors similar to the ones in this issue?

http://issues.umbraco.org/issue/U4-7869

James,

Not that I can see well take another peek though. Also we will upgrade to 7.3.7 ASAP. Hopefully that my fix it, Jeavon's investigations look very promising, also his coding skills there are a good reason for his back to back MVP's the guy is a legend!!

Cheers

Ismail

Guys,

Still getting this issue at least once every 2 weeks. Anyone seen this before?

I did see this in the umbracolog:

ERROR Umbraco.Core.UmbracoApplicationBase - An unhandled exception occurred

System.UnauthorizedAccessException: Access to the path 'D:\home\site\wwwroot\App_Data\TEMP\ExamineIndexes\RD000D3A203E7D\External\Index\segments.gen' is denied. at Lucene.Net.Store.SimpleFSDirectory.OpenInput(String name, Int32 bufferSize) at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit) at Lucene.Net.Index.SegmentInfos.Read(Directory directory) at Lucene.Net.Index.SegmentInfos.ReadCurrentVersion(Directory directory) at Lucene.Net.Index.DirectoryReader.IsCurrent() at Lucene.Net.Index.DirectoryReader.DoReopenNoWriter(Boolean openReadOnly, IndexCommit commit) at Examine.LuceneEngine.Providers.LuceneSearcher.ValidateSearcher(Boolean forceReopen) in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\LuceneSearcher.cs:line 359 at Examine.LuceneEngine.Providers.LuceneSearcher.GetSearcher() in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\LuceneSearcher.cs:line 239 at Examine.LuceneEngine.Providers.BaseLuceneSearcher.Search(ISearchCriteria searchParams, Int32 maxResults) in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\BaseLuceneSearcher.cs:line 175 at Application.BusinessLogic.Services.SearchService.SearchTalentByUrl(String type, String urlPart) in e:\TeamCity\buildAgent3\work\98d835a35a6fb5ea\Source\Application.BusinessLogic\Services\SearchService.cs:line 252 at Application.BusinessLogic.Services.TalentDetailService.GetTalentByUrl(String type, String urlPart) in e:\TeamCity\buildAgent3\work\98d835a35a6fb5ea\Source\Application.BusinessLogic\Services\TalentDetailService.cs:line 109 at Application.Web.ContentFinders.TalentContentFinder.TryFindContent(PublishedContentRequest request) in e:\TeamCity\buildAgent3\work\98d835a35a6fb5ea\Source\Application.Web\ContentFinders\TalentContentFinder.cs:line 33 at System.Linq.Enumerable.Any[TSource](IEnumerable1 source, Func2 predicate) at Umbraco.Web.Routing.PublishedContentRequestEngine.FindPublishedContent() at Umbraco.Web.Routing.PublishedContentRequestEngine.FindPublishedContentAndTemplate() at Umbraco.Web.Routing.PublishedContentRequestEngine.PrepareRequest() at Umbraco.Web.UmbracoModule.ProcessRequest(HttpContextBase httpContext) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Regards

Ismail

Sebastiaan,

We are using Azure. Currently in ExamineSettings.config we have

<Examine RebuildOnAppStart="false">

We did this because we thought the issue was after doing deploys the index was getting rebuilt and barfing. So looking at http://issues.umbraco.org/issue/U4-5993 we have 2 options:

1.Sync 2.LocalOnly

With RebuildOnAppStart set to false if we use either of those 2 options then after a deploy to bin would index get trashed thus requiring manual rebuild?

Regards

Ismail

Okay, so you tried to work around what exactly? Do you have a huge index?

In which case, I think Sync makes the most sense as the only thing it does is copies the existing indexes from the fileshare to your site's temp folder on the web worker. Then it updates both local and fileshare when updates are needed.

If you don't have a huge index that takes loads of time rebuilding then I would set RebuildOnAppStart to true again and see how it goes, and then use LocalOnly with that.

Sebastiaan,

I have turned this on for our staging site. I have also hit with some load and cannot get the indexes to fail over. However what I don't understand is how this swapping to TempStorage will fix the issue.

We are not load balancing we are on single azure website. So does azure on the hood do some voodoo nas stuff with website folders?

We just want to confirm this will work before trying it on live as we have a cranky client and do not want to promise any more false dawns.

Regards

Ismail

Firstly - it would seem that part of this problem is that you are using the old TempStorage (https://github.com/Shazwazza/UmbracoExamine.TempStorage) which is obsolete because the functionality is included in the Core. Further more, the functionality included in the core has many fixes and works much better. Secondly the legacy TempStorage provider is discontinued and will not longer be developed (i'll make a note of this on GitHub).

The only way that the index can get actually corrupted - meaning that it is unreadable/openable, for example if there are missing Lucene files is:

• If someone is mucking around with those files directly - never do this, read or writing
• If somehow the IIS process is unexpectedly terminated without warning specifically during the exact moment that Lucene is attempting to write files

Having "Sync" turned on doesn't mean whatsoever that there is more chance that your primary index storage (i.e. non temp storage) is more corruptible.

I plan on migrating this functionality into the Examine core at some stage whilst allowing more storage options for Azure but I have no time right now. The LocalOnly and Sync options are only available for Umbraco indexers/searchers, these options are not available for any custom indexers/searchers that you may have ... which is part of the reason this functionality needs to be migrated to Examine Core.

In the meantime, please ensure you are using the Umbraco Core indexers/searchers and not the TempStorage provider.

And as always, providing steps to reproduce goes a long way (once you are using the Umbraco Core indexers), this includes all information regarding how your environment is setup.

Shannon,

I am not using the obsolete package but using what is in core. We do not mess with lucene files directly in any way so rules that one out. The IIS process unexpectedly terminating could be a possibility.

We are not using any custom indexers just External and internal indexers.

I will keep an eye on it and if it goes again try and report back a bit more information.

Regards

Ismail

Here's the config we have on the site that loses indexed content most often and rebuild from a local server like so. (A couple others, but every six months) I guess it's like it should be?

<?xml version="1.0"?>
<!-- 
Umbraco examine is an extensible indexer and search engine.
This configuration file can be extended to add your own search/index providers.
Index sets can be defined in the ExamineIndex.config if you're using the standard provider model.

More information and documentation can be found on CodePlex: http://umbracoexamine.codeplex.com
-->
<Examine RebuildOnAppStart="false">
  <ExamineIndexProviders>
    <providers>
      <add name="InternalIndexer" type="UmbracoExamine.UmbracoContentIndexer, UmbracoExamine"
           supportUnpublished="true"
           supportProtected="true"
           runAsync="true"
           useTempStorage="Sync"
           analyzer="Lucene.Net.Analysis.WhitespaceAnalyzer, Lucene.Net"/>

      <add name="InternalMemberIndexer" type="UmbracoExamine.UmbracoMemberIndexer, UmbracoExamine"
           supportUnpublished="true"
           supportProtected="true"
           runAsync="true"
           useTempStorage="Sync"
           analyzer="Lucene.Net.Analysis.Standard.StandardAnalyzer, Lucene.Net"/>

      <!-- default external indexer, which excludes protected and unpublished pages-->
      <add name="ExternalIndexer" type="UmbracoExamine.UmbracoContentIndexer, UmbracoExamine"
           runAsync="true"
           useTempStorage="Sync"/>

    </providers>
  </ExamineIndexProviders>

  <ExamineSearchProviders defaultProvider="ExternalSearcher">
    <providers>
      <add name="InternalSearcher" type="UmbracoExamine.UmbracoExamineSearcher, UmbracoExamine"
           analyzer="Lucene.Net.Analysis.WhitespaceAnalyzer, Lucene.Net"
           useTempStorage="Sync"
           />

      <add name="ExternalSearcher" type="UmbracoExamine.UmbracoExamineSearcher, UmbracoExamine"
           useTempStorage="Sync"
           />

      <add name="InternalMemberSearcher" type="UmbracoExamine.UmbracoExamineSearcher, UmbracoExamine"
           analyzer="Lucene.Net.Analysis.Standard.StandardAnalyzer, Lucene.Net"
           enableLeadingWildcard="true"
           useTempStorage="Sync"
           />

    </providers>
  </ExamineSearchProviders>

</Examine>

@ismail Do you have runAsync="true" btw?
Strikes me that async combined with IIS process terminating might be the real purp.

Just FYI: runAsync="true" is totally unnecessary.

I need to understand what the actual issue people are seeing here is. 'Corrupted' could mean many things. Ismail is the only one that has posted a stack trace. Is this the exact same issue everyone is seeing?

    System.UnauthorizedAccessException: Access to the path 'D:\home\site\wwwroot\App_Data\TEMP\ExamineIndexes\RD000D3A203E7D\External\Index\segments.gen' is denied. at Lucene.Net.Store.SimpleFSDirectory.OpenInput(String name, Int32 bufferSize) at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit) at Lucene.Net.Index.SegmentInfos.Read(Directory directory) at Lucene.Net.Index.SegmentInfos.ReadCurrentVersion(Directory directory) at Lucene.Net.Index.DirectoryReader.IsCurrent() at Lucene.Net.Index.DirectoryReader.DoReopenNoWriter(Boolean openReadOnly, IndexCommit commit) at Examine.LuceneEngine.Providers.LuceneSearcher.ValidateSearcher(Boolean forceReopen) in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\LuceneSearcher.cs:line 359 at Examine.LuceneEngine.Providers.LuceneSearcher.GetSearcher() in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\LuceneSearcher.cs:line 239 at Examine.LuceneEngine.Providers.BaseLuceneSearcher.Search(ISearchCriteria searchParams, Int32 maxResults) in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\BaseLuceneSearcher.cs:line 175 at Application.BusinessLogic.Services.SearchService.SearchTalentByUrl(String type, String urlPart) in e:\TeamCity\buildAgent3\work\98d835a35a6fb5ea\Source\Application.BusinessLogic\Services\SearchService.cs:line 252 at Application.BusinessLogic.Services.TalentDetailService.GetTalentByUrl(String type, String urlPart) in 

From that stack trace it shows that temp storage is not used since it is trying to access the master index during searching.

@lars what does loses indexed content mean?

And when everyone says they are using 'Azure', I'm assuming you mean Azure Apps right? not Azure VMs?

By now I'm sure you realize that Azure web apps store all files on a remote file share which can cause all sorts of issues. This temp storage technique is currently the only way to resolve issues caused by how their infrastructure is setup. I have discovered that we can persist local files in a different persistent temp storage area on Azure instead of the ASP.Net temp files (which are prone to being cleared when /bin folder changes). The things I'd like to pursue sometime in the future are:

• Move this temp storage logic into Examine Core
• Add configuration options to store the temp date into the persistent temp storage area on Azure apps instead of ASP.Net temp storage
• Port the AzureDirectory blob storage functionality into Examine Core so that it works against Lucene 2.9 so people could have this option as well
• Test using the logic that exists in AzureDirectory to perform the Sync logic between the main index and the temp index instead of performing a backup/copy as it does now
• Create an Azure Search Examine provider - Darren already started this IIRC

I honestly have no idea when I'd find time to do any of this but it's on my ever growing TODO list... if anyone wants to help then lets start the discussion on the Examine GitHub repo.

Another thing to note is that Azure now supports running your sites 'locally' . I'm assuming they've enabled this feature specifically because people have so many problems running sites from remote file shares.

https://channel9.msdn.com/Shows/Cloud+Cover/Episode-201-Azure-Web-App-Local-Cache-with-Cory-Fowler

​"Local Cache enables your Apps to copy their code to storage on the local VMs running their site. Normally, Apps are run from a network based disk. Changing to storage local to the VM greatly improve the performance of languages like PHP, Node.js, and any other platform that needs to frequently read the files running it."​

@Shannon I'm sure I've sent you a few logs via zendesk with the only exceptions I have. Think I remember seeing the same as Ismail.

By "losing content" I mean that the index doesn't go corrupt. It goes empty and doesn't rebuild. Might end up with 0 docs, might end up with 5 docs. No apparent exceptions.

Anyway, I appreciate that this is close to impossible for HQ to tackle, and cross my fingers our collective efforts will solve this sooner or later.

Shannon,

We are running azure web app so hopefully the temp storage should fix the problem for us. Lars we are not doing runAsync=true however we have set

RebuildOnAppStart="false"

Just like you.

So for us mostly we end up with 0 documents in the index internal and external although we once had it that external had 5 docs we should have 20,000 plus in both.

Any ways fingers crossed the temp storage will resolve our issue. Will report back with any more issues.

Regards

Ismail

To re-iterate some facts:

• runAsync=true is irrelavent... Examine is always Async, never ever ever ever set this to false. Just remove this setting alltogether and it will run async by default
• RebuildOnAppStart - if this is false and you have no indexes then you have to manually build them. This setting does one thing: if your index doesn't exist during app startup, it will be created. If you set this to false and your index doesn't exist on app startup, then you will have no index at all and you will need to figure out how you get your index there.

@Shannon

The crux of our issue is documents ends up being 0.

So I guess we need to know what's causing that, and is there a possible fix/workaround?

Right.

We've got more or less the same numbers as Ismail. (0 or 5, but should have >20.000)

Just throwing out ideas here after skimming LuceneIndexer.cs:

• EnsureIndex does DeleteAll if forced. When is it forced?
• There are try/catches around, but do they really catch all exceptions? Any unhandled exception will make everything go bonkers when async
• There are commits. How about rollback on any exception?
• Only commit when done, so nothing happens if IIS process is ripped out from under our feet. (?)

Answers to your questions:

EnsureIndex does DeleteAll if forced. When is it forced?

Only here, this is how index rebuild works: https://github.com/Shazwazza/Examine/blob/master/Projects/Examine/LuceneEngine/Providers/LuceneIndexer.cs#L772

That said, this logic is unnecessary when rebuilding an existing index since Lucene can re-create an existing index using the same logic found in CreateNewIndex ( https://github.com/Shazwazza/Examine/blob/master/Projects/Examine/LuceneEngine/Providers/LuceneIndexer.cs#L732 ) without causing problems with current searches. See: https://github.com/Shazwazza/Examine/issues/37

There are try/catches around, but do they really catch all exceptions? Any unhandled exception will make everything go bonkers when async

yes they do during indexing, i've not seen any unhandled exceptions, any errors during indexing will be reported and there's an event

There are commits. How about rollback on any exception?

We don't commit if there are errors: https://github.com/Shazwazza/Examine/blob/master/Projects/Examine/LuceneEngine/Providers/LuceneIndexer.cs#L1545 It could be feasible to perform a rollback (which closes the writer) and then re-open the Writer. I don't think this is going to affect the issue you're seeing but could be worthwhile. If an error occurred though, you'd see it in your logs.

Only commit when done, so nothing happens if IIS process is ripped out from under our feet. (?)

Yes, this what happens: https://github.com/Shazwazza/Examine/blob/master/Projects/Examine/LuceneEngine/Providers/LuceneIndexer.cs#L1545

Regarding app restarts, see this code here when an indexer is disposed: https://github.com/Shazwazza/Examine/blob/master/Projects/Examine/LuceneEngine/Providers/LuceneIndexer.cs#L1856

When the webapp is shutdown it notifies all IRegisteredObject which is the ExamineManager: https://github.com/Shazwazza/Examine/blob/master/Projects/Examine/ExamineManager.cs#L310 which in turn disposes all indexers. If an Index Rebuild is currently happening and the app is shut off, we cannot just lock the app from shutting down and waiting until re-indexing is done since this would cause all sorts of problems. Instead the only option is to lock for a small amount of time (5 seconds) if there is still items in the queue and release when either the items in the queue are processed or the timeout is finished. This the only way I can see you ending up with 0 (or a few) items in your index - a rebuild was issued for one reason or another and the app domain shuts down.

Just wanted to reference my issue here, which sounds similar:

https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/75289-azure-website-not-initializing-examine-index-after-scaling

So my issue occurs after scaling or when Azure moves the host machine from under you, which is what might be happening to you guys when your issue only happens every couple of weeks. I've not resolved our issue yet as it fell down the priority list.

Hi all, just thought I'd post up this since it hasn't been documented yet (and i sort of forgot about it): http://issues.umbraco.org/issue/U4-7614

This is relevant to Azure only and allows for using a different persistent location for locally stored indexes instead of the volatile storage space that is ASP.Net temp files.

Shannon,

We are using 7.3.8 is this property tempStorageDirectory present in that version the issue tracker says its due in 7.3.5?

Also with Sync on our current location of index is

D:\local\Temporary ASP.NET Files\root\cb0cbdf4\7beae6bd\App_Data\TEMP\ExamineIndexes\RD000D3A207D42\Internal\

its in appdata not appcode so should not get cleared out after updates to bin?

Regards

Ismail

Shannon,

I did do rebuild yesterday and indexes were still there so will just leave it for now like this. Keeping an eye on it so far so good.

Regards

Ismail

Shannon,

The indexes died again. I will try tempStorageDirectory attribute see if that helps.

Regards

Ismail

Shannon,

Apologies for vague message. It had 0 documents I am using Sync but I do not have tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"

I am updating to that now hopefully that should fix up everything.

Regards

Ismail

Hi Shannon,

I can confirm we have this issue every time Azure moves us to a new host machine (I mentioned this above )

I keep an eye out for if we've been moved (in the umbracoServer DB table) and if we have I have to manually kick off the indexers. The same goes if manually scale out.

We are using the LocalOnly setting (as opposed to Sync) so the AppData\Temp path only contains empty folders at the moment.

James.

Ok, this sounds like the issue!! So YES you can fix this, just remove the {machinename}/ token from your paths.

This is there primarily for load balancers - so people don't have to manually configure this when they wish to load balance. I did not take into account this scenario when working in virtualized cloud appliances where sites are moved from one machine to another.

I'll update the defaults to not include this and update docs for load balancers who do actually require this setting.

@James - No Azure websites is not load balanced. There is no more than a single instance of a web worker accessing the db and file system at any given time. This is not load balancing. If you do run more than one instance - this can take several shapes:

• Scaling out on Azure websites
  • In this case - you would still require the {machinename} token so that your indexes are stored per machine
• Non Azure websites (i.e. VMs) and/or doing load balancing according to our docs
  • Requiring the {machinename} token would be dependent on how your file system is setup - shared vs replicated. If it is replicate the token is not required

@Lars - yes rebuildOnAppStart="true" (which is the default if not specfied) should trigger a full rebuild when no index exists. So I agree there is some other issue at play here. When you do scale out, it does rebuild the indexes on the newly created web workers, I've never seen this not happen in all of my tests. I would have to assume something quite specific happens when a site is moved to another worker/machine and is most likely due to something Azure does with it's file systems and controlling how ASP.Net app domains restart. Perhaps in some way Examine attempts to rebuild the index - this starts out by creating an empty index and then maybe based on some timing or whatever Azure is doing in the background it terminates the app domain again leaving an empty index. On the next restart Examine will not rebuild because there's a valid (although empty) index there.

It would be interesting to add Debug level logging to your Examine loggers so you can see the full log output of Examine during these times. You can do this without changing your global log4net logging level by targeting a specific logger, for example see: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web.UI/config/log4net.config under the <!--Here you can change the way logging works for certain namespaces --> text. You could add

<logger name="UmbracoExamine.DataServices">
    <level value="DEBUG" />
</logger>

There's certainly a way that we can work around this behavior I just need to determine if it's an Examine change needed or if it should be in UmbracoExamine, but we could:

• On app start when no indexes are detected and are scheduled to be rebuilt, we create marker files for each index
• When indexes are rebuilt, these marker files are removed
• If the app domain is terminated before the rebuild occurs, the marker files will remain
• During app startup we also check for these marker files, if they exist but a valid index is there, we still rebuild

@Shannon - Do you mean to say Azure websites is not load balanced unless you scale out? Since an Azure website can be scaled at any time (if enabled) I would always want to configure an Azure website to work in a load-balanced manner, even if it runs as one instance 90% of the time.

I haven't specified rebuildOnAppStart so should be using the default of "true". I posted my trace logs on the following forum post previously:

https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/75289-azure-website-not-initializing-examine-index-after-scaling

Hope that helps.

Hello,

Is there a status update on this issue? We've got an Azure website where scaling is enabled. For now we removed the {machinename} token and everything seems to be working.

Jeroen

@jeroen If you are scaling, then perhaps it's better to have 2x scaled out websites setup - and to reiterate - you MUST have {machinename} in the path when you are scaling out. In this setup, you would have 2 instances that are active, one of which should certainly have available indexes, if the other one gets moved to another server and needs to rebuild, Azure should consider that one non responsive and send more requests to the one that does have an index available. Then when you scale out more, yes each one would need to rebuild there as well.

@all:

Currently there is no perfect solution to this, you would need to write your own until we can have something in place which may require updates to Examine and/or UmbracoExamine. To solve your problem, here's what you can do:

• Clone the https://github.com/azure-contrib/AzureDirectory and backport it to work with Lucene 2.9
• Create sub classes of the examine indexers and searchers shipped with Umbraco and use an AzureDirectory instance instead of the default lucene Directory instance

What AzureDirectory does is similar to what Umbraco is doing:

• It stores the master index in Blob storage
• Only a master server can write to it
• For each slave server, the blob storage index files are synced to the local machine

OR

• There's potentially an ' easy' solution in which you just deal with the fact that the index will need rebuilding on new workers (or if workers are moved between hosts)
• In this case we can terminate any request coming to the website when we detect an index or the app isn't ready, returning a 503 with a retry-after-header. This should tell the Azure Load Balancer that the node isn't ready and the Azure LB will try again based on it's own timeout.

OR

• During startup you could have some logic to detect if there isn't an index on the slave server
• In that case you could create some sort of REST endpoint on your master server that your slaves could talk to and request a snapshot of the index which they can download and store locally

OR

• Attempt to create an Azure Search or Elastic Search Examine provider and host indexes in a centralized place

OR

• If it's just the Member index that is the main problem regarding rebuilding - only the back office member search uses the member indexer, I don't believe there is anything else in the core that specifically uses the Member indexer
• You could disable the member indexer and index members in your own custom way with Azure Search, Elastic Search, etc... and use those APIs to search your member data

Due to the nature of Azure, the way it structures it's file systems, the way it virtualizes things and moves sites between workers - there isn't a perfect solution that we can simply ship with from an Umbraco core perspective that will solve everyone's particular problems. Not everyone uses Azure, and there would probably be other/different issues with other virtualized hosts that can scale out - and again, a specific solution would probably need to be created for that in one way or another.

I would certainly enjoy some help with any of this since there is quite a lot of options, work, etc...

Guys,

We took out machine name from the config and we turned on tempStorage. It all seemed to be working fine however now we get regular:

 System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\local\Temporary ASP.NET Files\root\a38b9d33\a911d035\App_Data\TEMP\ExamineIndexes\Internal\segments_7'.

at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit) at Lucene.Net.Index.DirectoryReader.Open(Directory directory, IndexDeletionPolicy deletionPolicy, IndexCommit commit, Boolean readOnly, Int32 termInfosIndexDivisor) at UmbracoExamine.UmbracoExamineSearcher.OpenNewReader() at Examine.LuceneEngine.Providers.LuceneSearcher.ValidateSearcher(Boolean forceReopen) in x:\Projects\Examine\Examine\Projects\Examine\LuceneEngine\Providers\LuceneSearcher.cs:line 307 --- End of inner exception stack trace ---

Errors. For now i have turned off tempstorage and will see how it behaves. So no machine name in config and auto rebuild is false. My question I guess for Shannon will this still barf as azure does it voodoo? If it does then I am going to have to do 2am index daily rebuilds?

Regards

Ismail

Shannon,

I had:

                  <add name="InternalIndexer" type="UmbracoExamine.UmbracoContentIndexer, UmbracoExamine"
          supportUnpublished="true"
          supportProtected="true"
             useTempStorage="Sync"              
          tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"
          analyzer="Lucene.Net.Analysis.WhitespaceAnalyzer, Lucene.Net"/>

So useTempStorage=sync and tempstorage directory was for local azure storage. Using Umbraco 7.3.8 so this should not be using folder like

D:\local\Temporary ASP.NET Files\root\a38b9d33\a911d035\App_Data\TEMP\ExamineIndexes\Internal

I am confused?

Regards

Ismail

Shannon,

One thing in the issue tracker you mention:

NOTE: Just like the useTempStorage option, this would need to be specified for the searcher as well.

So in my config for the searcher bit i should have:

useTempStorage="Sync"
       tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"

as well?

So my whole examinesettings.config should look like:

  <add name="InternalMemberIndexer" type="UmbracoExamine.UmbracoMemberIndexer, UmbracoExamine"
       supportUnpublished="true"
       supportProtected="true"
         useTempStorage="Sync"
       tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"
       analyzer="Lucene.Net.Analysis.Standard.StandardAnalyzer, Lucene.Net"/>

    <!-- default external indexer, which excludes protected and unpublished pages-->
    <add name="ExternalIndexer" type="UmbracoExamine.UmbracoContentIndexer, UmbracoExamine" 
         useTempStorage="Sync"
         tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"/>
</providers>

  <add name="ExternalSearcher" type="UmbracoExamine.UmbracoExamineSearcher, UmbracoExamine"  useTempStorage="Sync"
       tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"/>

  <add name="InternalMemberSearcher" type="UmbracoExamine.UmbracoExamineSearcher, UmbracoExamine"  useTempStorage="Sync"
       tempStorageDirectory="UmbracoExamine.LocalStorage.AzureLocalStorageDirectory, UmbracoExamine"
       analyzer="Lucene.Net.Analysis.Standard.StandardAnalyzer, Lucene.Net" enableLeadingWildcard="true" />

</providers>

Regards

Ismail

Just to chime in here, we're having identical issues to Ismail. Even though everything's set to use Sync, the Internal Indexer occasionally craps out looking for the segments file in the ASP.Net temp folder, rather than the user temp folder.

If you upgrade to Examine 0.1.69-beta it's easier to use AzureDirectory like Shannon described here: https://our.umbraco.org/forum/extending-umbraco-and-using-the-api/74731-examine-corruption-issues#comment-244293

I've got it working and my Examine indexes are now stored in blob storage. More info about my setup in this topic: https://our.umbraco.org/forum/extending-umbraco-and-using-the-api/78818-using-azuredirectory-with-examine

Jeroen

How's the performance of the blob storage provider?

is working on a reply...