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

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.

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.

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.

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.

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.

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.

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.