(SOLVED) Rebuild search indices broke search ability in Providence/Pawtucket

clovescat

Hello!I was attempting to customize our search results relevance by BOOSTing some fields, and weren't seeing any changes. I read that rebuilding the search indices might help that problem. So I rebuilt them but now search is completely broken! I set the search_indexing.conf back to its "original settings" but the search seems to only return 0 results for everything. How can I get my search results back?

clovescat

Oh I should mention I did this by "pressing the button" in the admin panel, not by running caUtils.

Jonathan

Did you rebuild the index after resetting search_indexing.conf to the original configuration, or only before? Also, since you are running it via the web rather than in terminal, make sure the process completes (sometimes it can die in a browser timeout).

clovescat

Yup! I ran it again after setting it back to make sure it wasn't an error I introduced. The process completed successfully (both times). Is there anything else I can try to clear things up?

Jonathan

I'm not sure actually. Try clearing the cache in app/tmp and double check that there isnt any search indexing file stored in your /local folder in /app/conf. If that doesnt work, please provide more detail about what isnt searchable. (Is searching by identifier broken, or is it everything?)

clovescat

Searching by everything is broken, everything returns 0.It seems if I save something and try to search for it, it comes back. A potential fix could be to force a re-save on everything if there's an easy way to do that algorithmically?I'll try these two things now, thanks very much!

clovescat

Nope, clearing out the cache in app/tmp didn't bring anything back, and there isn't a search indexing file in my local folder in /app/conf. argh!Yeah, if I save a record, it will update the index appropriately and those things again become search-able. But I want everything to be search-able again. I also want to be able to fix this original issue (which was results ranking relevance only by idno ascending order even if "relevance" was first in line, and not by metadata, titles, etc., things more interesting).

clovescat

Permissions should be open and consistent on the server, but maybe there's a place I can check in particular that would cause the reindexing services to not update, but comes back to life when manually saving?

seth

Have you tried reindexing using caUtils?

Also can you post (or share) your search_indexing.conf file?

clovescat

search_indexing.conf is exactly as found on github in /providence.We are also using Pawtucket, and the search_indexing.conf for it is the same as found in pawtucket2! I will try re-indexing via CLI now, thanks!

seth

Ok, well make sure it is exactly the same... if you accidentally deleted a curly bracket all sorts of things can happen. And if command line reindexing doesn't work you should see something to tell you why. Let me know what that is. Unless it works, in which case enjoy the rest of the day.

clovescat

Aha! More useful, possibly, an error message and a stack trace! :D First things look good:Done! [Indexing for entities, occurrences, object representations, list items, set items, objects, relationship types, sets, users, user groups, storage locations, object lots, tour stops, tours, object checkouts, movements, comments, collections, tags, places, loans took 1 minute, 14 seconds]Note that if you're using an external search service like ElasticSearch, the data may only now be sent to the actual service because it was buffered until now. So you still might have to wait a while for the script to finish.But then...PHP Fatal error:  Uncaught exception 'DatabaseException' with message 'Got a packet bigger than 'max_allowed_packet' bytes' in /Library/WebServer/Documents/providence/app/lib/core/Db/mysqli.php:316Stack trace:#0 /Library/WebServer/Documents/providence/app/lib/core/Db/DbStatement.php(151): Db_mysqli->execute(Object(DbStatement), Object(DbStatement), '\n\t\t\tINSERT  INT...', Array, NULL)#1 /Library/WebServer/Documents/providence/app/lib/core/Db.php(270): DbStatement->executeWithParamsAsArray(Array)#2 /Library/WebServer/Documents/providence/app/lib/core/Plugins/SearchEngine/SqlSearch.php(1856): Db->query('\n\t\t\tINSERT  INT...')#3 /Library/WebServer/Documents/providence/app/lib/core/Plugins/SearchEngine/SqlSearch.php(253): WLPlugSearchEngineSqlSearch->flushContentBuffer()#4 [internal function]: WLPlugSearchEngineSqlSearch->__destruct()#5 [internal function]: CLIUtils::rebuild_search_index(Object(Zend_Console_Getopt))#6 /Library/WebServer/Documents/providence/support/bin/caUtils(166): call_user_func_array('CLIUtils::rebu in /Library/WebServer/Documents/providence/app/lib/core/Db/mysqli.php on line 316Then that same stack trace repeats itself.

clovescat

Is there somewhere in the configuration where I need to identify and bump this number?

seth

Yes, that would be in your server's mysql config file. Oftentimes the location is /etc/mysql/my.cnf, but it can be in other locations as well. Bump it up to a large value (256M?). It's a ceiling, not a resource allocation.

clovescat

Gotcha. Great, thanks very much! I'll try it out, which may involve asking someone with more authority than me, but I'll report back!

clovescat

That worked. If anyone else runs into this problem:  I bumped it up to 256 in /etc/mysql/my.cnf and because I didn't want to restart mysql, I logged in and set global max_packet_size 256*1024*1024. Will update as resolved, thanks!

Laith2001

@clovescat thank you for this problem thread, I'm having the same problem and followed your steps, and only solved part of the problem, many objects can be searched by label now, but still not by other fields. Some other files are the opposite.
I'm using version 1.8, and tried with both sqlsearch2, and elasticsearch.

seth

When you ran the reindex it ran to completion?

Laith2001

Yes, I ran php caUtils rebuild-search-index and got the result
Done! [Indexing for objects, set items, object representations, list items, relationship types, users, sets, user groups, storage locations, places, entities, collections, loans, tags, occurrences, movements, tours, object lots, tour stops, comments, object checkouts took 3 hours, 44 minutes, 49 seconds]
Note that if you're using an external search service like ElasticSearch, the data may only now be sent to the actual service because it was buffered until now. So you still might have to wait a while for the script to finish.

seth

Where did you get the code you're running? GitHub? If so, which branch and what commit?