As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

Gives same error in Apache in local XAMPP installation.Also, in XAMPP after increasing memory limit, gives the following error : "Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 261904 bytes) in D:\xampp\htdocs\lib\pkp\classes\file\FileManager.inc.php on line 337"

A new database installation works fine by the way...

Any Insights please... The old database contains 4500 users and 750 articles, so it is really troublesome to do a new mysql database installation...

Can I ask how much memory does the whole system have that you are running this on?

From the messages you have given it seems like the system may be starved for memory. The 503 Error from the web server "Service unavailable" indicates a temporary overloading or maintenance of the server (http://www.checkupdown.com/status/E503.html). This could be a memory issue. Additionally the memory error you posted" Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 261904 bytes) in D:\xampp\htdocs\lib\pkp\classes\file\FileManager.inc.php on line 337" shows that it has trouble allocating a chunk of RAM to handle the request.

Might I suggest that you reboot your server, make sure everything starts up properly and see if the error does go away as a first step to resolving this.

If the system still has issues afterwards please post the relevant parts of your web server error log showing any entries that are relevant to the time in which you are seeing the error.

What page are you on when you receive the "out of memory" error? 256MB ought to be enough allocated to PHP for a single request. (In my experience, rebooting doesn't affect this kind of issue.)

Regards,Alec SmecherPublic Knowledge Project Team

bdgregg wrote:Can I ask how much memory does the whole system have that you are running this on?

Thank you for helping out Brian and Alec... Your help is much appreciated...Firstly the memory limit as Alec suggested was already increased to 256MB and still memory allocation failed, as you can see...Rebooting the server in VPS and XAMPP was also done several times and in other two servers. memory allocation error was seen only in XAMPP local installation. In my Los Angeles VPS with 2GB RAM, the database upgrade from 2.3.3.2 to 2.4.1 went okay but with same error with page load failed in the page http://website.com/index.php/xxxx/edito ... eview/xxxx. it occurs after selecting reviewer and then clicking on the notify reviewer button. I have to specify that this error never occurs in a fresh installation with new database; so may I suggest that we can safely rule out 2.4.1 installation file system bugs and may be because there is some goof up in the database upgrade process from 2.3.3.2 to 2.4.1 ??? My production site runs in a reseller and shared centos 5 and 6 with cpanel. The error was duplicated with all kinds of server modes- Apache with mod_php, mod_php; mod_php_ruid2, su_php variations etc with path_info on and off... php version upgrade by ISP to 5.3.8 with shared server failed my OJS-2.3.3.2 running version, that is why I had to upgrade in the first place....I am attaching the debug output from the error page too below...I can actually give you people the whole Los Angeles High RAM VPS login where the old and new journal systems are tested in; so that you can see the logs and stuff... It is running on kloxo now, with centos 5.8

That's strange, because the "notify reviewer" function isn't one of the more memory-intensive ones. It suggests to me that you're hitting some kind of recursion limit due to memory usage.

Could you try resetting the file permissions in your files directory (the one configured under files_dir in config.inc.php)? All contents and subdirectories need to be writable by the account under which PHP scripts run (which will depend on what SAPI you're using).

The permissions in files_dir location were "0755" for folders and "0644" for files...When same files directory was tested with old installation of 2.3.3.2 with old dataabase, there is no notification e-mail page error...Also, Author e-mailing and Editor-emailing from the same page works fast with absolutely no database lag !!!The files directory comes to about 1GB, so we were using the same files storage directory for upgraded and old installation testing...Also now tested with a new files directory with file permissions 0755 for folder and 0644 under public_html for files_dir and the error is present...

The permissions as far as I can see, are set okay in the shared server with cpanel where upgraded installation was running and also in VPS test server.Is there any permission differences for files directory between OJS 2.3.3.2 and OJS 2.4.1 ?

Thank you Alec...Because we couldn't find any workable solutions this far; we have started the long and arduous process of exporting and importing issues into a fresh database for 2.4.1.0...Anyway; I have kept copies of old and problem databases; just in case you would suggest some workable solutions...

Hmm, I suspect you're going to spend a lot of time avoiding a fix that'll turn out to be pretty trivial in the end. I'm wondering why a notification link would end up trying to make a directory anyway; if you drop a fatalError('...') call into that function temporarily (near where the code is dying), and turn on stack traces in config.inc.php, it would be a good start to tracking it down.

That I would try and get back to you...But I am happy to say that I found out how to get out of this problem; at least partially...The problem seems to be in selecting the second option of E-Mailing Reviewer the submission during Notifier function - which is in setup-policies. The Notifier function goes through normally when standard review is selected...which I accidentally found out just today...

So, as you have suggested, the TemporaryFileManager.inc.php seems to be called only when E-Mail attachment option is selected and then the memory error props up...