https://doc.sitecore.com/developers/90/platform-administration-and-architecture/en/using-solr-auto-suggest.html
If you need more references. Set all parameters yourself, don’t rely on defaults. > On Nov 21, 2019, at 3:41 PM, Dave <hastings.recurs...@gmail.com> wrote: > > https://lucidworks.com/post/solr-suggester/ > > You must set buildonstartup to false, the default is true. Try it > >> On Nov 21, 2019, at 3:21 PM, Koen De Groote <koen.degro...@limecraft.com> >> wrote: >> >> Erick: >> >> No suggesters. There is 1 spellchecker for >> >> <str name="queryAnalyzerFieldType">text_general</str> >> >> But no buildOnCommit or buildOnStartup setting mentioned anywhere. >> >> That being said, the point in time at which this occurs, the database is >> guaranteed to be empty, as the data folders had previously been deleted and >> recreated empty. Then the docker container is restarted and this behavior >> is observed. >> >> Long shot, but even if Solr is getting data from zookeeper telling of file >> locations and checking for the existence of these files... that should be >> pretty fast, I'd think. >> >> This is really disturbing. I know what to expect when recovering now, but >> someone doing this on a live environment that has to be up again ASAP is >> probably going to be sweating bullets. >> >> >> On Thu, Nov 21, 2019 at 2:45 PM Erick Erickson <erickerick...@gmail.com> >> wrote: >> >>> Koen: >>> >>> Do you have any spellcheckers or suggesters defined with buildOnCommit or >>> buildOnStartup set to “true”? Depending on the implementation, this may >>> have to read the stored data for the field used in the >>> suggester/spellchecker from _every_ document in your collection, which can >>> take many minutes. Even if your implementation in your config is file-based >>> it can still take a while. >>> >>> Shot in the dark…. >>> >>> Erick >>> >>>> On Nov 21, 2019, at 4:03 AM, Koen De Groote <koen.degro...@limecraft.com> >>> wrote: >>>> >>>> The logs files showed a startup, printing of all the config options that >>>> had been set, 1 or 2 commands that got executed and then nothing. >>>> >>>> Sending the curl did not get shown in the logs files until after that >>>> period where Solr became unresponsive. >>>> >>>> Service mesh, I don't think so? It's in a docker container, but that >>>> shouldn't be a problem, it usually never is. >>>> >>>> >>>> On Wed, Nov 20, 2019 at 10:42 AM Jörn Franke <jornfra...@gmail.com> >>> wrote: >>>> >>>>> Have you checked the log files of Solr? >>>>> >>>>> >>>>> Do you have a service mesh in-between? Could it be something at the >>>>> network layer/container orchestration that is blocking requests for >>> some >>>>> minutes? >>>>> >>>>>> Am 20.11.2019 um 10:32 schrieb Koen De Groote < >>>>> koen.degro...@limecraft.com>: >>>>>> >>>>>> Hello >>>>>> >>>>>> I was testing some backup/restore scenarios. >>>>>> >>>>>> 1 of them is Solr7.6 in a docker container(7.6.0-slim), set up as >>>>>> SolrCloud, with zookeeper. >>>>>> >>>>>> The steps are as follows: >>>>>> >>>>>> 1. Manually delete the data folder. >>>>>> 2. Restart the container. The process is now in error mode, complaining >>>>>> that it cannot find the cores. >>>>>> 3. Fix the install, meaning create new data folders, which are empty at >>>>>> this point. >>>>>> 4. Restart the container again, to pick up the empty folders and not be >>>>> in >>>>>> error anymore. >>>>>> 5. Perform the restore >>>>>> 6. Check if everything is available again >>>>>> >>>>>> The problem is between step 4 and 5. After step 4, it takes several >>>>> minutes >>>>>> before solr actually responds to curl commands. >>>>>> >>>>>> Once responsive, the restore happened just fine. But it's very >>> stressful >>>>> in >>>>>> a situation where you have to restore a production environment and the >>>>>> process just doesn't respond for 5-10 minutes. >>>>>> >>>>>> We're talking about 20GB of data here, so not very much, but not little >>>>>> either. >>>>>> >>>>>> Is it normal that it takes so long before solr responds? If not, what >>>>>> should I look at in order to find the cause? >>>>>> >>>>>> I have asked this before recently, though the wording was confusing. >>> This >>>>>> should be clearer. >>>>>> >>>>>> Kind regards, >>>>>> Koen De Groote >>>>> >>> >>>
