OJS 3.4 Production Workflow Becomes Unresponsive During Large Issue Scheduling and DOI Registration Process

Hello everyone,

We are currently experiencing a complex issue in our Open Journal Systems (OJS) 3.4 installation that appears to affect multiple parts of the editorial and production workflow. The problem started after migrating our journal platform from an older OJS version to a fresh OJS 3.4 environment running on a Linux server with PHP 8.1 and MariaDB. Since the migration, editors have reported intermittent delays when accessing submissions, scheduling articles into future issues, and performing publication-related tasks. While the site remains accessible to readers, the editorial backend frequently becomes slow or unresponsive during periods of heavy activity. No obvious PHP fatal errors are displayed in the browser, making it difficult to determine the root cause.

One of the most concerning symptoms occurs when editors attempt to schedule multiple accepted articles into a new issue. The scheduling interface loads correctly, but after selecting articles and saving changes, the page either remains in a loading state indefinitely or returns a generic server error. In some cases, the issue appears to be created successfully, but the assigned articles are not actually linked to the issue in the database. When editors refresh the page, the issue configuration may partially persist while article assignments disappear. This inconsistent behavior creates uncertainty regarding whether editorial actions have been saved correctly and increases the risk of duplicate work.

We have also noticed problems during DOI registration and metadata export operations. When attempting to register DOIs through the configured registration agency plugin, the process occasionally stalls without generating any confirmation message. Server resource utilization increases significantly during these operations, and background tasks appear to remain active longer than expected. In addition, metadata exports that previously completed within a few seconds now require several minutes or terminate unexpectedly. We are unsure whether the DOI registration issue is directly related to the workflow slowdown or whether both problems are symptoms of a deeper database or application-layer bottleneck.

To troubleshoot the problem, we enabled application debugging, reviewed web server logs, examined database performance metrics, and checked scheduled task execution. The logs contain occasional warnings related to database queries and cache operations, but there are no consistent fatal exceptions that clearly identify the source of failure. Database tables were optimized and indexes reviewed, yet the behavior remained unchanged. We also temporarily disabled several non-essential plugins to determine whether a third-party extension was contributing to the issue. Although minor performance improvements were observed, the core problem affecting issue scheduling and DOI processing persisted.

Another observation is that the issue becomes more noticeable when multiple editorial users are logged in simultaneously. During periods when several editors are processing submissions, assigning copyeditors, or updating publication metadata, response times increase dramatically. This has led us to wonder whether there may be a locking, queue-processing, caching, or session-management problem occurring behind the scenes. We have verified that file permissions appear correct and that storage directories are writable, but we are uncertain whether there are additional configuration parameters that should be reviewed for high-volume editorial workflows.

Has anyone encountered a similar situation in OJS 3.4 where issue scheduling, publication assignment, DOI registration, and metadata export functions become unstable after a migration or upgrade? We would appreciate guidance regarding specific log files, database tables, queue services, cache settings, or known compatibility issues that should be investigated further. Any recommendations for diagnosing hidden performance bottlenecks, identifying problematic queries, or validating the integrity of migrated publication data would be extremely helpful. Thank you for your time and assistance.

Hi @deenjames,

Unfortunately that doesn’t give me too much to go on – you’ve already reviewed the logs, which is the best starting point. If you find yourself buried in too many log entries, make sure to turn debug to Off.

What release of OJS 3.4 are you using? If it’s out of date, you might consider updating to the latest. This is much simpler than a major upgrade like 3.3 to 3.4, and may result in a number of bugfixes.

Is the issue reproducible, or does it only appear at random?

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks for the follow-up. We’re currently running OJS 3.4, though I’m going to double-check whether we’re fully up to date on the latest maintenance release, since it’s possible some of the behavior could already be addressed by bug fixes. The issue isn’t entirely random, but it’s also not consistently reproducible. We tend to see it more often during heavier editorial activity, particularly when multiple editors are scheduling articles, updating metadata, or performing DOI-related tasks at the same time.

One thing that makes troubleshooting difficult is that the symptoms vary. Sometimes issue scheduling appears to save successfully but article assignments disappear after a refresh, while DOI registration or metadata exports may stall without any clear error message. Since the logs haven’t revealed a definitive root cause yet, I’m planning to collect more detailed information around the exact conditions under which the problem occurs, including concurrent user activity, database performance, and plugin interactions. Are there any specific OJS 3.4 log locations, database tables, or known migration-related issues that you would recommend examining more closely when workflow actions partially complete but do not persist correctly?

Hi @deenjames,

The most helpful thing would probably be to use the browser’s web development tools to watch what happens to the latest request when the problem occurs, i.e. what the response code from the server is. However, you’ll have to have the Network tab open and active in the web dev tools at the time the error occurs, which could be tricky if you aren’t able to cause the problem to appear consistently.

Regards,
Alec Smecher
Public Knowledge Project Team