No results in search

edited May 2017 in General Support
I was going through my site today preparing for a demo tomorrow and discovered that search does not appear to be working. Quicksearch for both Providence and Pawtucket doesn't return any results nor does Advanced Search in Providence. Browse is OK. The last time it worked was two days ago. We set up some search forms for representations and were with using set tools to add objects to sets. 

I don't want to monkey around too much with configs or source code on the eve of a demo, but based on some other discussion threads here I have deleted the contents of app/tmp and pawtucket/app/tmp. I've run the maintenance for rebuilding the search indices. I've made sure search cache is disabled where applicable. It was off in Providence but not Pawtucket. 

Thanks for any troubleshooting hints you might have.

I'd also add that I'm seeing this error a lot in debugging: 
[/app/lib/core/Search/SearchEngine.php@217] SEARCH cache miss for 787fc1cc4e472ab3a7abc448199ea1f6

[/app/lib/ca/Browse/BrowseEngine.php@1012] Cache expire for a36c6e9d1d6b5692085c717aaf480fdainfo
[/app/lib/core/Search/SearchEngine.php@217] SEARCH cache miss for 7316603a7f515db4e8e78d683c54a341info


  • I don't want to say my troubles are over, but I found a thread from sophie that recommended disable_out_of_process_search_indexing = 1 in app.conf to solve another indexing problem. So despite my decree to not fiddle with configs, I did that and rebuilt indices and had instantly better results. That did not solve cache miss and cache expire warnings, but for demo purposes I feel better. 
  • Cache misses are normal – it just means the result isn't in the cache yet. It's entirely possible that out of process indexing is failing on your server, especially if it's on a shared server or behind a firewall. Spawning index tasks in PHP is a bit of a nightmare hack, and while it generally works well (which is why it's on by default) it definitely does not play well in some environment.

    So I would leave it off. If it's working for you, then it's working :-)

  • Sad to say that my search problem has re-emerged insofar as searches are not returning any results. So I'm actually not sure that out of process indexing was relevant at all. I've tried the setting both ways today in an effort to get it going again today.

    Search did seem to have been working mostly ok until I re-indexed one last time today (why, oh why did I do that?), which appears to have broken it.

    So I'm wondering about troubleshooting steps.

    Thanks for any suggestions.


  • I wanted to note that I merged in the 1.7.3 changes today and it didn't change my search issue.
  • Hi aj,

    When I search on the wildcard (*) I get 85 object results with the link you provided.  Can you switch to the fully updated default theme and see if you are seeing the same search problem with the standard frontend?
  • Thank for taking a look.

    I switched to the updated default theme and saw the same problem. I also see it in the Providence UI.

    The interesting thing is that the wildcard returns the number of results I'd expect, but if I use any word that's in a description, name or entity, I don't get any results.
  • Are you using the default configuration files on the backend?
  • Yes, for the most part. The only thing I tweaked in the Providence source code was the OpenLayers script to add some GoogleMaps layers choices that I couldn't seem to achieve through a conf file. In conf files I disabled some unneeded editors and made some changes with media processing. And enabled more support for representations on the same level as objects. Created a few users. Some views and search forms.

    But I'm done with this phase of the project; we'd just finished needing the search forms. So if you think it would be a good idea to move the default conf files back in place and rebuild the indices then I could try that. Or if there's something in the database I could look at, I'd be open to suggestions.

  • edited May 2017
    Reporting back...I put the default conf files in place and re-indexed. It didn't change the results.

    In the mean time, I went dumpster diving through Apache log files. A grep for "Search" seems to have revealed an out-of-memory error for php during indexing. Looks promising.  I'll fiddle with that. No need to respond unless this elicits something you've seen before. I'll report back. The entries seem to correspond to when I first made this thread.

    Sample (remaining errors attached):

    PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 1153083 bytes) in /var/www/html/cax/app/lib/core/Db/mysqli.php on line 316, referer:
  • So, for the sake of posterity and anyone who finds this thread years from now, I increased php's max memory from 128M to 256M. That didn't work by itself. But I could see in the Apache logs that CA error handler was was trying and failing to write an array to the browser (but at least php wasn't crashing).

    PHP Warning:  Error while sending STATISTICS packet. PID=18384 in /var/www/html/cax/app/helpers/errorHelpers.php on line 58, referer:

    So I took a look in the CA application log, which is the next function in the error handler script. The mysqld service had offered the following error.

    DatabaseException: Got a packet bigger than 'max_allowed_packet' bytes

    So I went into my.cnf and increased the max_allowed_packed size from 1M to 16M, which I think should be good for a database that doesn't contain blobs. I think I got the original values when I sized the server by copying the "medium" template to my.cnf. 

    I rebuilt the indices and search was working again.
Sign In or Register to comment.