Episerver.Search exception when processing the queue

Erik Norberg

Vote:

On odd occassions we seem to be getting these confusing errors from episervver.search:

RequestQueue failed to retrieve unprocessed queue items. Message: Object reference not set to an instance of an object.
Stacktrace: at EPiServer.Search.Data.Internal.SearchFactory.ConstructSyndicationItem(IndexRequestQueueItem queueItem)
at EPiServer.Search.Data.Internal.SearchFactory.GetUnprocessedQueueItems(String namedIndexingService, Int32 pageSize, Collection`1& ids)
at EPiServer.Search.Internal.RequestQueueHandler.ProcessQueue()

Apart from the rather bad error handling(throwing exception inside a loop and by the look of it discarding whatever was read from the database, default is 50 records), it leaves us with very little to go on.

However there are some strange things going on here that i wonder if they can't be related.

These IndexRequestQueueItem are stored in their very own DDS and not the regular one and unlike every other DDS post i have seen each item is represented by not one but by two rows in the database.

Could these Null reference exceptions be from an underlying bug in the DDS that it doesn't always read the rows in the right order?

The only thing i see used on row #2 is Indexed_String01 that stores the NamedIndexingService(for us this is rather redundant as we only have the one). Why is this on it's own row? Why aren't this stored on row #1 Indexed_String01 through 03?

Much appreciated if anyone could shed some light on this

#186492

Dec 20, 2017 17:20

Sebastian Lundh

Vote:

Usually the best way to troubleshoot problems with Episerver search is by monitoring requests between service and application but in this case it looks like the error occurs before recieving/sending anything to the service. So I guess probably the best would be to see what is actually loaded from the database when this occurs with sql profiler. I don't know regarding the rows but It might be possible to copy out the code to run it locally and step through?

#186516

Dec 21, 2017 12:57

Erik Norberg

Vote:

Yes when the exception occurs there won't be a request to the service.

SQL profiler doesn't help, the offending item is removed from the database before the exception is thrown.

I can't reproduce it locally so debugging it is rather difficult, most likely there is an issue with a handful of production content but there is no telling which ones.

If only the exception was thrown when populating the queue and not when processing it.

The reading of the rows should be fine, a closer look at VM_IndexRequestQueueDataStore shows it handles it well, while it is totally unnecessary it shouldn't result in any read issues as long as that view is used.

#186636

Dec 28, 2017 17:16