On 8/7/2019 4:23 AM, HTMLServices.it via dovecot wrote:
Thanks Shawn for your reply I tried to bring the heap size to 5gb as you would like, but the problem was not solved.
That machine only has 4GB of total memory, so setting the heap to 5GB will eventually be problematic and lead to major performance issues. If I were doing this with that hardware, I would set the heap to 1GB to start and maybe go as high as 2 GB. With only 28000 documents, this *should* be enough.
"/If you have configured fts_solr with a URL that contains a # character, it's never going to work./" I'm not sure how to configure this but in the 90-plugins.conf file I configured this:
plugin { #setting_name = value fts = solr fts_solr = url = http://5.39.2.59: 8987/solr/dovecot/ }
That URL looks good. It doesn't have the # character, and from what I can see, should be completely correct.
Note that you should restrict access to the Solr server, not allow the Internet to reach it. With it publicly accessible, anyone can delete the entire index or issue queries that cause denial of service. I was able to connect to it, and I can see that your Solr index has no data in it:
https://www.dropbox.com/s/9bsx2vfu3kab19j/dovecot-solr-user-issue-screenshot...
I don't know if it's empty because nothing ever got indexed, or if it's empty because somebody found the URL for your server on this mailing list and decided to delete your index.
If I attempt a query on your index, it fails, complaining that there is no _text_ field:
http://5.39.2.59:8987/solr/dovecot/select?q=hello
The solrconfig.xml file that is in the dovecot source should be setting the df parameter to a field that exists, perhaps "body". The field that it is using does not exist in the schema that is also in the dovecot source.
It might be that when fts_solr issues queries, it qualifies everything to search specific fields. If that's what it does, then this configuration issue would not break fts_solr in the wild.
Thanks, Shawn