In somewhat specific situations, running updatesearchindexsolr.php may fail, if the following conditions are met:

• An installation has a very large subtree
• The MySQL connection wait_timeout is lower than the total amount of time it takes for the script to terminate execution

The script will (silently-ish) fail since mysql will go away. The script attempts to split its workload by launching new processes for each subtree (each top subtree?), which inherently receives a new database connection instance. However, if a subtree is very large, that entire subtree will be handled by a single process in one go, and in a scenario where the script takes very long to execute, it may exceed the wait_timeout value of the mysql server on the other side.

This can be verified to be the case by forcing the eZDB instance to reconnect more often, by manually unsetting the global db instance (eZDB takes care of reconnecting once that's gone).

Steps to reproduce:

• Generate a large subtree of indexable objects
• Set the mysql server's wait_timeout to a low value
• Run updatesearchindexsolr.php, verifying that it takes longer to index a single sub-tree than the maximum time set in wait_timeout