Evented indexing on multiple servers

Vote:
 

Hi!

How does evented Find indexing work when running multiple servers, for example one front server and a integration server?

I know that the queue is stored in the [tblFindIndexQueue] in the database by default but how is it processed? Is it processing the queue from multiple servers simultaneously or only one of them on the configured indexQueueInterval? Could one server use one queue, and the other server a different queue theoretically? Are there any recommendations on setting this up?

Thanks

#248708
Feb 16, 2021 11:08
Vote:
 

Hi Mattias

We recommend allowing any instance to write to the queue but only process it from one instance.The bottleneck will be the Find service anyhow and having multiple instances processing the queue could in some scenarios be heavy on the database with your occasional lock.

Put something like this in your initialization

// Always add events to the indexing queue
EPiServer.Find.Cms.EventedIndexingSettings.Instance.EventedIndexingEnabled = true;

// Only pull items from the queue and index if scheduled jobs are enabled
EPiServer.Find.Cms.EventedIndexingSettings.Instance.ScheduledPageQueueEnabled = IsDedicatedIndexingInstance;

#248713
Edited, Feb 16, 2021 14:50
Vote:
 

Thanks!

In our case, the integration server is mostly receiving products from PIM system, so it will not be any modifications of normal CMS content on that server. The frontserver will not do any modifications of product data so it will not queue up any product modifications. Would it be possible to use in memory queue on the integration server in this scenario and allow both servers to process it's own queue? The reason for this is that we have deadlock issues when using one database queue.

#248715
Feb 16, 2021 15:49
Vote:
 

I guess both ScheduledPageQueueEnabled AND EventedIndexingEnabled could be disabled for the Front server. Front servers will synced with updates right? We don't want them to processed by multiple instances/servers.

The deadlock issues we've been seeing recently in regards to the tblFindIndexQueue comes from loading items from the queue and adding items to the queue.

'Loading items to the queue' benefits from only one instance polling the queue. Also, important is not to poll too frequent. Default is 5 seconds.

'Adding items to the queue will' will see a lock-fixing-bug/improvement in upcoming Find release.

I am not really sure why there needs to be more than one queue. I don't think there is there is a memory queue implementation available but maybe you are refering to the Invisible mode that skips the queue and index items directly? That's not really recommended if it can be avoided.

#248716
Edited, Feb 16, 2021 16:16
Vote:
 

Sorry, I was not being clear on the server scenario. Front server also includes the CMS where the editors are updating CMS content. Integration server is only responsible for running scheduled jobs and importing catalog from PIM system. So no content editing on the integration server.

In memory queue implementation would be a custom implementation and only enabled on the integration server. But it would be great if you would fix the deadlock issues. Then this wouldn't be needed of course.

We currently have polling configured to 10 seconds.

#248717
Edited, Feb 16, 2021 16:31
Vote:
 

Then I suggest as I did intially that only the integration server, in this particular setup, only does the processing of the queue.

Do you have some more information to share on those deadlocks? Just to make sure these upcoming fixes cover them as well.

#248719
Edited, Feb 16, 2021 17:03
Vote:
 

Ok, thanks.

I don't have the full stack trace available now for the deadlock issue but it often happens when importing full Catalog.xml from PIM through Mediachase.Commerce.Catalog.ImportExport.CatalogImportExport. The error causes the entire import to fail. When disabling evented indexing, the error doesn't occur. This is the error message:

System.AggregateException: One or more errors occurred. ---> System.Data.SqlClient.SqlException: Transaction (Process ID 107) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

#248720
Feb 16, 2021 17:16
Vote:
 

If you can make sure only one instance reads and process and this queue I believe the upcoming improvements to SQL stored procedures that are responsible for adding items to the queue would suffice.

I think I should be able to provide you with a pre-release if you want to evaluate.

#248736
Feb 16, 2021 20:47
Vote:
 

Thanks, but I have created an admin tool to disable evented indexing before running full catalog import, so it's not that critical I would say and we can wait for the official release. During normal operation it's working OK.

#248760
Feb 17, 2021 7:33
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.