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

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

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