Indexing Processor State is Closed

roxana.todoran

Vote:

Hi,

I am currently working on a project which is using EPiServer 7.5.

We are facing an issue for some time, regarding the Indexing Processor State. It frequently changes to “Closed”.

Note: The Commerce Manager code has been customized so that “Build/Rebuild Index” buttons are always displayed regardless of the processor state, but they shouldn’t be displayed at all.

We noticed that a restart site from IIS or a click on the “Invalidate” button restore the state (to “Invalid”), but the issue keeps reappearing.

We are using Solr Search Provider and have created our custom class for indexing. Basically, we are importing prices and inventory and managing the catalog (product information, availability) from Commerce Manager.

Any thoughts?

Thank you,

Roxana

#113615

Nov 25, 2014 16:31

Jeff Valdez

Vote:

Hi Roxana,

Could you post the contents of the packages.config file at your web root?
I'd like to verify the versions of the Commerce packages you're using.
You noted that you customized the code-behind for the view (IndexTab.ascx) within Commerce Manager.
Have you customized any code inside the Mediachase.Search.Solr35SearchProvider project?
I'm going to do some decompilation and see what's setting this status.

Thanks,
Jeff

#113715

Edited, Nov 26, 2014 20:07

roxana.todoran

Vote:

Hi Jeff,

Thank you for your quick response. Actually, only a restart from IIS seemed to fix the issue; invalidate had no effect. We did this yesterday and today it's still ok.

But what does "Closed" state mean? What causes this state to appear?

To answer your questions:

1. The EPiServer versions from web project -> packages.config are:

<package id="EPiServer.CMS.Core" version="7.9.0" targetFramework="net40" />
<package id="EPiServer.CMS.UI" version="7.9.1" targetFramework="net40" />
<package id="EPiServer.CMS.UI.Core" version="7.9.1" targetFramework="net40" />
<package id="EPiServer.Commerce" version="7.9.0" targetFramework="net40" />
<package id="EPiServer.Commerce.Core" version="7.9.0" targetFramework="net40" />
<package id="EPiServer.Commerce.UI" version="7.9.0" targetFramework="net40" />
<package id="EPiServer.CommonFramework" version="7.5.446.2" targetFramework="net40" />
<package id="EPiServer.Framework" version="7.9.0" targetFramework="net40" />

2. Yes, we did some customizations to the Mediachase.Search.Solr35SearchProvider project. Unfortunatelly, I cannot upload the dll on the forum and I couldn't find your email address either. Here is mine: roxana.plaian@techromix.com. Can you please send me a quick email so that I can reply.

Thank you,

Roxana

#113746

Nov 27, 2014 11:04

Jeff Valdez

Vote:

Hi Roxana,

Thank you for the information provided over the US holiday break, specifically your Bealls.Solr35SearchProvider.dll assembly. I haven't yet been able to ascertain any fault in the decompiled source of the assembly you proivded. However, I've done some research into the CMS and Commerce assemblies involved (Mediachase.ConsoleManager.dll, EPiServer.Events.dll) down to the database layer and I know where the closed status is being set.

What I'm missing is a little more information on how to accurately reproduce the issue in order to report the bug adequately. Could you provide some more information around the characteristics of the issue? Perhaps the amount of time elapsed beetween IISRESET seeing the "Closed" state. Does the issue occur during peak or non-peak hours? How often is indexing happening? What is the magnitude of changes to content? Could you possibly do a test run with your system with a more verbose logging setting (Error, Debug, etc.) and try and see if you get any exception stack traces or other output in your logs when you witness the "Indexing processor state is Closed" message?

In case you're also researching the issue these are the following assemblies, types (decompiled source), stored procedures, and tables I've looked into:

Types:

Mediachase.Commerce.Manager.Apps.Core.Search.Tabs.IndexTab, Mediachase.ConsoleManager
EPiServer.Events.ChangeNotification.IChangeNotificationManager, EPiServer.Events
EPiServer.Events.ChangeNotification.Implementation.ChangeNotificationManager, EPiServer.Events
EPiServer.Events.ChangeNotification.Implementation.ManagedChangeProcessor, EPiServer.Events
EPiServer.Events.ChangeNotification.Implementation.ManagedChangeProcessor`1, EPiServer.Events
EPiServer.Events.ChangeNotification.EventQueue.InMemoryQueue`1, EPiServer.Events
EPiServer.Events.ChangeNotification.EventQueue.InDatabaseQueue`1, EPiServer.Events
EPiServer.Events.ChangeNotification.ChangeProcessorStatus, EPiServer.Events

Stored procedures:

[ChangeNotificationGetStatus]
[ChangeNotificationAccessConnectionWorker]

Tables:

[tblChangeNotificationProcessor]
[tblChangeNotificationConnection]

If you follow the trail from IndexTab down through the weeds, the stored procedure [ChangeNotificationAccessConnectionWorker] only sets the processor status to 'closed' if there is a null valued ProcessorId column from [tblChangeNotificationProcessor]. However, I'm still unclear as to what would cause this condition. Perhaps a null joining row in [tblChangeNotificationConnection], though I doubt it. It's a bit deep at this point.

Hopefully with more information from you we can create a clearer picture and get to the bottom of it.

Thanks,
Jeff

#114209

Edited, Dec 05, 2014 22:34