Vulnerability in EPiServer.Forms
I am prepping the new site on the production environment (2 Web servers). Search service is installed on the sepeare box. Whenever I am trying to reindex I do get the following error:
2016-04-07 13:33:04,295  ERROR SearchSettings: Update batch could not be sent to service uri 'http://192.168.2.104/IndexingService/IndexingService.svc/update/?accesskey=xxxxx'. Message: 'The remote server returned an error: (500) Internal Server Error. at System.Net.HttpWebRequest.GetResponse() at EPiServer.Search.RequestHandler.MakeHttpRequest(String url, NamedIndexingServiceElement namedIndexingServiceElement, String method, Stream postData, Action`1 responseHandler) at EPiServer.Search.RequestHandler.SendRequest(SyndicationFeed feed, String namedIndexingService, Collection`1 ids)'2016-04-07 13:33:04,295  ERROR SearchSettings: Send batch for named index 'serviceName' failed. Items are left in queue.
It is worth mentioning that the main site is running under SSL.
I noticed that the search services does create Index folder and a Main subfolder in it. It does create a write.lock for a couple of seconds and then deletes it
I would appreciate any pointers.
Just noticed that tblIndexRequestLog table has over 17m records!
Check that you have updated to latest nuget packages for search service so that you don't have a version mismatch. That one got me before with a similar error...
Large number of rows in tblIndexRequestLog indicates that the indexing is not working; the old indexing requests are getting queued one after another. 17M rows is a lot and will never finish even once you get the indexing working, so I would recommend just deleting the rows and reindexing the content with http:///EPISERVERUI/cms/admin/indexcontent.aspx.
Furthermore, episerver is constantly trying to index the entries in tblIndexRequestLog which will only cause additional overhead. Normally this table should be empty (it's a queue for content indexing).
Btw. with 17M rows in tblIndexRequestLog your DB is likely bloated (like over 10+ GB), so after deleting the rows, consider shrinking the DB with SQL Server Management Studio :)
I did truncate this table a few times. Redeployed the indexer a few times. Nothing seems to be helping at the moment. The indexer does work on staging env, but no production. Sort of ran out if ideas :(
You checked that you have enabled it for remote request as well? Default is localhost only.
Thank you for your post. I restarted the IIS and it started working - wierd!!! Anyway, it's been running for over 24h hours now and it not it is not even 1/4 way through. (0.5m records in the tblIndexRequestLog). Is it supposed ot be taking that long?
Heh! When in doubt, IIS reset :)
Sounds like very poor performance yes. At least that's something to work with. I've never had any problems with index taking long no...
I normally run Find on bigger solutions though. Might want to check cpu, firewalls messing it up, too few available threads etc. IIS logs is a good place to start...