After updating to version 3.4.0-3 I have a white screen and error 500.
I’m using apache 2.4.57 with php-fpm 8.0.27 and postgresql 13.11.
File /var/log/php-fpm/www-error.log:
[05-Sep-2023 11:29:21 America/Sao_Paulo] PHP Fatal error: Uncaught Error: Call to a member function getOption() on null in /var/www/revistas/html/cache/t_compile/b9da708b775ca192cb9735589afa7e98b537357a^e64e579388e5615e11e939b12134d6ae8679eba6_0.app.frontendpagesindexJournal.tpl.php:37
Stack trace: #0 /var/www/revistas/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_64f71a227782f5_90996604() #1 /var/www/revistas/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #2 /var/www/revistas/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #3 /var/www/revistas/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render() #4 /var/www/revistas/html/lib/pkp/lib/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute() #5 /var/www/revistas/html/lib/pkp/classes/template/PKPTemplateManager.php(1325): Smarty_Internal_TemplateBase->display() #6 /var/www/revistas/html/pages/index/IndexHandler.php(80): PKP\template\PKPTemplateManager->display() #7 [internal function]: APP\pages\index\IndexHandler->index() #8 /var/www/revistas/html/lib/pkp/classes/core/PKPRouter.php(334): call_user_func() #9 /var/www/revistas/html/lib/pkp/classes/core/PKPPageRouter.php(277): PKP\core\PKPRouter->_authorizeInitializeAndCallRequest() #10 /var/www/revistas/html/lib/pkp/classes/core/Dispatcher.php(165): PKP\core\PKPPageRouter->route() #11 /var/www/revistas/html/lib/pkp/classes/core/PKPApplication.php(387): PKP\core\Dispatcher->dispatch() #12 /var/www/revistas/html/index.php(21): PKP\core\PKPApplication->execute() #13 {main}
thrown in /var/www/revistas/html/cache/t_compile/b9da708b775ca192cb9735589afa7e98b537357a^e64e579388e5615e11e939b12134d6ae8679eba6_0.app.frontendpagesindexJournal.tpl.php on line 37
[05-Sep-2023 11:29:21 America/Sao_Paulo] Illuminate\Queue\MaxAttemptsExceededException: PKP\migration\upgrade\v3_4_0\jobs\FixRegionCodes has been attempted too many times or run too long. The job may have previously timed out. in /var/www/revistas/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Queue/Worker.php:746
Stack trace: #0 /var/www/revistas/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(505): Illuminate\Queue\Worker->maxAttemptsExceededException() #1 /var/www/revistas/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(415): Illuminate\Queue\Worker->markJobAsFailedIfAlreadyExceedsMaxAttempts() #2 /var/www/revistas/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(375): Illuminate\Queue\Worker->process() #3 /var/www/revistas/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(326): Illuminate\Queue\Worker->runJob() #4 /var/www/revistas/html/lib/pkp/classes/core/PKPQueueProvider.php(104): Illuminate\Queue\Worker->runNextJob() #5 /var/www/revistas/html/lib/pkp/classes/queue/JobRunner.php(220): PKP\core\PKPQueueProvider->runJobInQueue() #6 /var/www/revistas/html/lib/pkp/classes/core/PKPQueueProvider.php(128): PKP\queue\JobRunner->processJobs() #7 [internal function]: PKP\core\PKPQueueProvider->PKP\core{closure}() #8 {main}
Regarding the fatal error, I have no idea what it could be or what to do.
As for the FixRegionCodes problem, I noticed that it triggers a query in the database that takes about 50 minutes to complete:
UPDATE metrics_submission_geo_daily AS gd
SET region = rm.iso
FROM region_mapping_tmp AS rm
WHERE gd.country = rm.country AND gd.region = rm.fips
In my OJS installation this table has 70550964 records.
Is it right that this query is executed every time the site is opened?
Oh, you have really big DB tables for statistics/metrics!
The upgrade to 3.4 creates FixRegionCodes jobs for each country from this list: https://github.com/pkp/pkp-lib/blob/stable-3_4_0/lib/regionMapping.php.
Some region codes (those listed in that file) changed, and FixRegionCodes jobs try to change the entries in your DB tables appropriately. The fix is not needed in order for OJS to work, but in order for your Geo data statistics to be correct.
Because a job handles only one country I thought the job execution should not take too long. But, it seems with that amount of data it is a problem
The jobs are per default executed on a request. Also, per default max 30 jobs are run per request (s. “Job Queues Settings” in config.inc.php).
See also https://docs.pkp.sfu.ca/admin-guide/en/deploy-jobs – how else jobs could be run (using a cron or a worker).
I see two possibilities to fix this FixRegionCodes problem:
It would maybe be best if you would at least only temporarily run the jobs using a cron or a worker. You would then also need to see what jobs failed to re-run them.
I could create another migration scripts that would try to fix those region codes in the DB, that you could run in the background, so that it can take looooong/as much time as needed to execute. Then you would need to remove the FixRegionCode jobs.
Let me know what solution you would like to try (first), and we can see further…
OK. That means your 3.4.0-3 installation is already in production?
Are you able to follow how such a FixRegionCodes job is handled then using the cron, and if it finishes?
In the production environment, we are still using version 3.2.1.1.
We haven’t been able to update yet because all the midway versions had some difficulty, either because we use postgresql here or because of the massive amount of data we have in our base. Or even due to some data consistency error in our database.
Anyway, since ALM was implemented in OJS we use CRON to run scheduled jobs.
That’s because at that time ACRON used to run two access log processing tasks at the same time. Sometimes three. As this generated a discrepancy in the access and download data, we chose to use CRON to run it daily.
It will probably still take some time for us to actually update, we have a problem registering emails in the users table. This field was not case sensitive, so we have the same e-mail registered a few times with uppercase and lowercase letters.
Ah, OK.
However, note that scheduled tasks is not the same as jobs. Jobs were introduced first now, in 3.4.
Are you maybe able to test CRON with jobs (and especially that FixRegionCode jobs) on a test system?
@Tarcisio_Pereira I don’t think even using the cron to run queue job will not be good enough considering you have such a huge table records . And Job Runner definitely will not work for you either . For this kind of case, we suggest to use worker thread to handle queue jobs and mamage through a daemon monitoring service , more details at https://docs.pkp.sfu.ca/admin-guide/en/deploy-jobs
Now as this is a one time job to run to complete the upgrade process, you can use the work thread as one time command just to complete the upgrade process as
php lib/pkp/tools/jobs.php work --timeout=5000
I suggest you push back the particular job from failed list to back to queue again and run the above command . note that here the timeout flag set for how long a job may run for max time in seconds and I am guessing in your case, it will take some good amount time so set it accordingly . you can handle the failed job redispatching back to queue from admin section or through following command
php lib/pkp/tools/jobs.php failed --redispatch
and see the failed jobs list
php lib/pkp/tools/jobs.php failed
Please run the command php lib/pkp/tools/jobs.php usage see more details about job command line tool .
