November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
Turns out there is confusion over EPi 7 and EPiServer.Search. EPi 7 does not use the Indexing Service that's hooked into Windows...
The issue still remains, but it's solely related to the site (maybe configuration, but all looks correct), the site's IndexingService.svc, and possibly server access rights (I'm starting to think that's not the case).
Have you checked your errorlogs? I have almost the same problem. The search indexing worked just fine on the devenvironment (Win 7 Ultimate N) however when I moved the site to the server (Win Server 2008 R2) the index folders are not even created. I cannot find the service either. However when checking the errorlogs I retrieve the following error:
2013-04-25 09:52:39,515 [6] ERROR SearchSettings: Update batch could not be sent to service uri 'http://192.168.54.125:17000/IndexingService/IndexingService.svc/update/?accesskey=local'. 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)'
2013-04-25 09:52:39,515 [6] ERROR SearchSettings: Send batch for named index 'serviceName' failed. Items are left in queue.
2013-04-25 09:52:42,671 [7] ERROR SearchSettings: Could not reset index '' for service uri 'http://192.168.54.125:17000/IndexingService/IndexingService.svc/reset/?namedindex=&accesskey=local'. 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.ResetIndex(String namedIndexingService, String namedIndex)
2013-04-25 09:52:42,671 [7] ERROR SearchSettings: Could not reset index '' for service uri 'http://192.168.54.125:17000/IndexingService/IndexingService.svc/reset/?namedindex=&accesskey=local'. 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.ResetIndex(String namedIndexingService, String namedIndex)
2013-04-25 09:53:09,578 [7] ERROR SearchSettings: Update batch could not be sent to service uri 'http://192.168.54.125:17000/IndexingService/IndexingService.svc/update/?accesskey=local'. 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)'
2013-04-25 09:53:09,578 [7] ERROR SearchSettings: Send batch for named index 'serviceName' failed. Items are left in queue.
I then tried to access the same URL via a browser and then I also get the 500-error (as in the error). Maybe this is normal when you try to access it through a browser, I do not know.
Got any input on my errors? The same as yours?
First of all... We got this to a working state that we are happy with...
I think the issue is [partially] because we are running on Windows Server 2008 R2. If we removed all of the index files, it would throw errors for each queued item to be indexed. The errors look like its related to a write lock on the directory:
2013-04-29 09:58:04,137 [5] ERROR IndexingService: Failed to delete Document with id: 3caae094-1d4b-447a-b1f2-bafe4707e43b|en-US. Message: no segments* file found in Lucene.Net.Store.SimpleFSDirectory@C:\EPiServer\Sites\MySite\AppData\Index\Main lockFactory=Lucene.Net.Store.NativeFSLockFactory: files:
at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit)
at EPiServer.Search.IndexingService.IndexingServiceHandler.DeleteFromIndex(NamedIndex namedIndex, String itemId, Boolean deleteRef)
2013-04-29 09:58:04,184 [5] ERROR IndexingService: Failed to search index 'default'. Index seems to be corrupt! Message: no segments* file found in Lucene.Net.Store.SimpleFSDirectory@C:\EPiServer\Sites\MySite\AppData\Index\Main lockFactory=Lucene.Net.Store.NativeFSLockFactory: files:
at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit)
at Lucene.Net.Search.IndexSearcher..ctor(Directory path, Boolean readOnly)
at EPiServer.Search.IndexingService.IndexingServiceHandler.SingleIndexSearch(String q, NamedIndex namedIndex, Int32 maxHits, Int32& totalHits)
2013-04-29 09:58:04,246 [5] ERROR IndexingService: Failed to search index 'default'. Index seems to be corrupt! Message: no segments* file found in Lucene.Net.Store.SimpleFSDirectory@C:\EPiServer\Sites\MySite\AppData\Index\Main lockFactory=Lucene.Net.Store.NativeFSLockFactory: files:
at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit)
at Lucene.Net.Search.IndexSearcher..ctor(Directory path, Boolean readOnly)
at EPiServer.Search.IndexingService.IndexingServiceHandler.SingleIndexSearch(String q, NamedIndex namedIndex, Int32 maxHits, Int32& totalHits)
2013-04-29 09:58:04,246 [5] ERROR IndexingService: Failed to write to index: 'default'. Message: no segments* file found in Lucene.Net.Store.SimpleFSDirectory@C:\EPiServer\Sites\MySite\AppData\Index\Main lockFactory=Lucene.Net.Store.NativeFSLockFactory: files: write.lock
at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit)
at Lucene.Net.Index.SegmentInfos.Read(Directory directory)
at Lucene.Net.Index.IndexWriter.Init(Directory d, Analyzer a, Boolean create, Boolean closeDir, IndexDeletionPolicy deletionPolicy, Boolean autoCommit, Int32 maxFieldLength, IndexingChain indexingChain, IndexCommit commit)
at Lucene.Net.Index.IndexWriter..ctor(Directory d, Analyzer a, Boolean create, MaxFieldLength mfl)
at EPiServer.Search.IndexingService.IndexingServiceHandler.WriteToIndex(String itemId, Document doc, NamedIndex namedIndex)
So, we tried adding the index from our local dev environment to the server, and we noticed the index files were being added updated as expected. The only error we got after that looked like this:
2013-04-29 10:16:11,613 [5] ERROR IndexingService: Reset of index: '' failed. Index not found!
2013-04-29 10:16:11,707 [9] ERROR SearchSettings: Could not reset index '' for service uri 'https://mysite.com/IndexingService/IndexingService.svc/reset/?namedindex=&accesskey=local'. 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.ResetIndex(String namedIndexingService, String namedIndex)
This error was odd because the service was returning named indexes just fine. Plus, we think this error occured only when it tried to delete the current index. Since this is not something we are doing, nor do we really want to do it, we're ignoring this issue.
Once we starting setting this up on the production server (a Windows Server 2012 machine), we noticed things were working as expected. We could delete all the index files and folders, and it would create it as expected.
@David: I do recall seeing an error like yours after we started testing on the production server. The issue in our case was the path to the indexing service was wrong. Try hitting the path it's returning (http://192.168.54.125:17000/IndexingService/IndexingService.svc) and see if the page says "Endpoint not found." If it returns anything other than that, either the path is wrong, or something else is messed up.
I solved my problem. It was that I had multiple sites on the same server that uses indexing. I changed multipleSiteBindingsEnabled to true and reindexed the site.
@Chris, There is another way to solve this is to stop IIS, then remove index folder, and then start IIS again.
Hi, I've tried everything you have suggested by now.
The URLs mentioned above are /IndexingService/IndexingService.svc and /IndexingService/IndexingService.svc/update are working as expected. The search works when I search for page ID, but now when I search page name.
Is there something I should enable somewhere that I haven't?
I ran into this general issue as well. I was checking the error logs and noticed that the IndexingService in our production environment is still using the path from our development environment. I attempted Huy's idea of stopping removing the folder and starting the iis backup but nothing regenerated. I must missed the path in the error log before but noticed it now. I will work on changing that path and let you all know what happens. Any idea on how to change the path??
Bumping this thread.
Now it seems that have runned in the same problem that you Marija.
Did you found a solution why the search only works for id:s and not for page names?
Same issue for me as well.
Have any of you (Marija, Andreas) found a solution?
Actually, I don't know. :)
I removed the index files, restarted the indexing job and then after a while the search started to work again.
I have found out that even if the job says it's done. It's not. It still working in the background, so you have to wait for a while after the done and see if it's works.
Exactly the same for me, I realized at some point that all I lacked was patience - to wait for the pages to get reindexed.
Update: we had an issue setting up the search on an Intranet. The Intranet wasn't accessible from the machine where it's hosted, hence the indexingservice/indexingservice.svc gave 401, too. However, the error in the log was misleading:
"Send batch for named index 'serviceName' failed. Items are left in queue."
What we did was to add a binding to localhost:12345 in IIS and then changed the path in web.config file to localhost:12345/indexingservice/indexingservice.svc instead of sitepath/indexingservice/indexingservice.svc.
Hope this will help someone.
I can pitch in here our solution when we had the problem where errors like these were generated:
2013-04-29 09:58:04,246 [5] ERROR IndexingService: Failed to search index 'default'. Index seems to be corrupt! Message: no segments* file found in Lucene.Net.Store.SimpleFSDirectory@C:\EPiServer\Sites\MySite\AppData\Index\Main lockFactory=Lucene.Net.Store.NativeFSLockFactory: files: at Lucene.Net.Index.SegmentInfos.FindSegmentsFile.Run(IndexCommit commit) at Lucene.Net.Search.IndexSearcher..ctor(Directory path, Boolean readOnly) at EPiServer.Search.IndexingService.IndexingServiceHandler.SingleIndexSearch(String q, NamedIndex namedIndex, Int32 maxHits, Int32& totalHits)
This was on a prod server running windows server 2012.
Our error was that there was something fishy about the Index folder, if we tried setting everyone full control, windows would give an error saying it could not set those access rights for the subfolders. This, interesting enough, happened even if we deleted the entire index folder and recreated it. When we created a folder with another name and updated the index directoryPath in web.config, the site started to index again.
I just removed that port from the default install, then the service became accessable.. gah
My solution of the error "IndexingService: Failed to search index 'default'. Index seems to be corrupt! Message: Could not find file '...\App_Data\Index\Main\segments_e4q'." was to remove content of App_Data\Index folder, restart the application (by a change of web.config) and execute indexing in the 'secret' interface: http://sitehost/EPiServer/CMS/Admin/IndexContent.aspx
My solution of the following error:
ERROR SearchSettings: Update batch could not be sent to service uri (400 Bad request)
1. In your solution (propably in the dev. env., using visual studio & nuget), run: "Update-Package -reinstall EPiServer.Search"
2. Visit your solution's packages folder, and locate the "EPiServer.Search.IndexingService.dll"
3. Copy that file manually into the bin directory (overwrite existing) of the web application at the server where the search does not work.
Hi,
Did you try to install the windows feature HTTP Activation for WCF 4.5 webservices? This feature is required for hosting WCF services (in IIS) using .Net 4.5. This feature can be enabled by opening the windows features installer "turn Windows features on or off". goto .NET Framework 4.5 Advanced Services > WCF Services > HTTP Activation.
Hope this helps.
Cheers,
Pierre
I solved my problem with no indexing by:
A) Creating hosts file entries on the server for the site
127.0.0.1 thesite.local
B) Then added this binding to the site with the port 2000
C) Then updating the relevent part of the web.config to this:
<add name="serviceName" baseUri="http://thesite.local:2000/IndexingService/IndexingService.svc"
D) Thats it.
Marshall
So I'm having some issues with EPiServer.Search (not Find) and the Indexing Service on one of our test servers, a Windows Server 2008 R2 box... The primary and current issue is that it's not creating the index files (like the segments file) in my Index folder in the VPP ("AppData"). When we remove both the "Main" and "Ref" folder, the re-index creates the "Main" folder, but does nothing else. These same steps on local dev work as expected.
I'm using EPiServer.Search.ReIndexManager() in a scheduled job to do the re-index. Both a scheduled and manual run of the job doesn't work.
The first issue we noticed was the Indexing Service on the machine was missing. And for some reason, we couldn't get the "Indexing Service" folder installed on the server (under C:\Program Files (x86)\EPiServer\Shared\Services). We tried re-installing all EPi 7, re-installing EPiServerSearch.msi, creating a new site with EPiServer Search on the server via Deployment Center, and installing the EPiServer Search module on the actual site via Deployment center.
We ended up manually installing the service by copying over the folder from our local dev environment, and hooking it up to the Windows Service via command line with help from this link: http://sdkbeta.episerver.com/SDK-html-Container/?path=/SdkDocuments/CMS/7/Knowledge%20Base/Developer%20Guide/Upgrading/Running%20CMS%206%20R2%20and%20CMS%207%20Side-by-Side.htm&vppRoot=/SdkDocuments//CMS/7/Knowledge%20Base/Developer%20Guide
At this point, the issue still remains, even after changing the "Log On As" user for the Windows Service to the App Pool user, which we had to do for the CMO Thumbnail service to work.
If I copy over the full index from our local dev, I can see that it does create/delete the other files in the "Main" folder related to the index, but it never updates the segments file. So I know, at least, the access rights for the app pool user in those folders are working. We just need this to work when we "start from scratch" by deleting the "Main" folder.
Any ideas?