Solr Indexing Timeout

The Solr Plugin stops indexing a 1/3 of the way into the process. Seems like there is some timeout, on the application level. For a second I saw something about editing some value in:
/application/models/Mixin

but it flashed and disappeared. Please let me know what I might need to do. Thanks.

The SolrSearch plugin uses a long-running job processor to handle reindexing, so it shouldn’t time out as part of your browser session. I would suggest first checking the application/logs/errors.log file in your Omeka directory (as long as you’ve set it up) to see if there are any relevant error messages. If not, I would then check your php.log file to see if the process may of ended unexpectantly, perhaps due to reaching a PHP time or memory limit.

Thank you. No error log. How do I setup for error logging? After I setup, I will re-run the solr indexer.

See here for documentation:
https://omeka.org/codex/Retrieving_Error_Messages

I both:
In .htaccess uncommented:
SetEnv APPLICATION_ENV development

set:
application/config/config.ini, and change the value of debug.exceptions to true

No errors are reported in errors.log, but indexing still ends 1/3 of the way through. Only difference is that the webpage does not disappear.

I have the following set in config.ini:
jobs.dispatcher.default = "Omeka_Job_Dispatcher_Adapter_Synchronous"
jobs.dispatcher.longRunning = “Omeka_Job_Dispatcher_Adapter_Synchronous”

Is this accurate to have both?

Finally an error in the browser:
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/library/legacy/application/libraries/Zend/Db/Select.php on line 628

the neighborhood of Select.php shows the following:
// Remove comments from SQL statement
$noComments = preg_replace(self::REGEX_SQL_COMMENTS, ‘$1’, (string) $val);
if (preg_match(self::REGEX_COLUMN_EXPR_ORDER, $noComments)) {
$val = new Zend_Db_Expr($val);
}
$this->_parts[self::ORDER][] = array($val, $direction);
}
}

Do you have any other ideas? Browser message says it fails in Select.php line 628

Is there a particular reason your jobs.dispatcher.longRunning is set the way it is? The default appears to be:

jobs.dispatcher.longRunning = "Omeka_Job_Dispatcher_Adapter_BackgroundProcess"

Receiving a fatal error from PHP that “Maximum execution time of 30 seconds exceeded” is likely because the indexing is taking longer than 30 seconds, not because there is an actual bug in Select.php. Using the BackgroundProcess adapter should launch a separate CLI php process to handle the indexing, and PHP frequently using different settings when executed in a CLI context including having no execution time limit.

Changed based upon:


and
http://omeka.org/forums-legacy/topic/solrsearch-empty-index

What do you suggest?

Plugin does not overwrite PHP.INI, so we temporarily open up max_execution limit in PHP to run and all works.