Does anyone know how to solve this problem...
I'm trying to run a java app from a php file (via http request). This is the output:



[Opened /usr/local/dh/java/jre/lib/rt.jar]
[Opened /usr/local/dh/java/jre/lib/jsse.jar]
[Opened /usr/local/dh/java/jre/lib/jce.jar]
[Opened /usr/local/dh/java/jre/lib/charsets.jar]
Error occurred during initialization of VM
Could not reserve enough space for code cache



It works fine if I use SSH and run the app at the cmdline.
Its a "hello world" style app, nothing complicated.

Any ideas??? anyone???

Thanks

What's your PHP code? You using a system() call in PHP to run it? If so, it sounds like you're running out of memory. Java is a memory HOG and it's quite possible that the VM is unable to start up cause the memory restrictions on PHP.

<?
exec('java -Xmx1024m -jar "/home/blahblahblah/mydomain/testjava/Test.jar"');
?>

I've also tried very low memory

<?
exec('java -Xmx32m -jar "/home/blahblahblah/mydomain/testjava/Test.jar"');
?>


But that fails in the same way. Much lower and the RT doesn't load at all.

I've checked the memory requirements when it does work and it is < 20MB.

Bet that's the problem. The max memory for PHP thread is like 8 or 12 megs. It's definatly not up into the 20s. I want to say 8 megs.

In reply to:

---

Could not reserve enough space for code cache

---

Note the reserved part. Note your command: -Xmx32m. Since max is set at 32megs, it needs to reserve 32 megs.

Java is a memory HOG. I'm not exagurating on that at all. What will take a normal application 2 megs to do, Java takes 10. And that is not an over-exaguration.

In reply to:

---

-Xmx1024m

---

Gah, 1 gig? geez....

Java has seriously spoiled programmers with memory allocations. I think Java programmers need to be retaunt "good" memory constraints. It's NOT good when your web application need 1 gig memory.....

The PHP address space sounds like the likely cause.
Note: it does work via SSH.

I'm not a linux developer, sounds like you might be:- Are you saying that exec() doesn't spawn a new process (with its own address space)?

I was assuming that java is not created as a child thread of the php thread, but a completely new process (as it is in Windows) - so it should obtain it own address space. I guess I am wrong.

Anyhow, I've dug a bit deeper and discovered that there is an acknowledged bug in the 64bit JVM5.0 branches:

http://forum.java.sun.com/thread.jspa?threadID=651637&start=15&tstart=0

The bug is not present in the 32bit version.
So is DH using 64bit or 32bit I wonder?

They're using 32bit version.

I'm trying to recall the differences between the command line invokers. I know there's subtles one. One of them waits for a return, another just keeps going.

As for the address space thing, I know what you're saying and to be honest, I can't say either way. The evidance shows that it's using PHP's space, but logic per other programming languages, it normally wouldn't.

Trying to figure out the details now, but not much info on that low of level.

Give shell_exec() a try and see if that helps anything.

IS there any other way of solving this problem?

The slowest thing about a java program is starting the VM, to do it on every request could be extrordinarily painful (even if you get it to run)

When I want to run a java program after a PHP request (the one time I've needed to do this) I simply have the PHP program write the appropriate information from the web/db to disk and then run the java program periodically out of cron. It reads the queued work and then processes it in its own time.

I've tried all the functions, they all fail with the same error.

It's probably not PHP, but the account the PHP process is running in...

I logged in using SSH and ran the PHP file that execs java:
php test.php
This worked. The JVM ran and the data was crunched.
If the theory about the PHP memory was correct, then then this should have failed with sme kind of memory exception.

However, http://www.domain.com/test.php still failed (ok this was expected).

(Note: In previously SSH tests I was directly running java on the cmdline, not through a PHP script)



This seems to suggest that because PHP _can_ launch java, something else must be blocking.

So, I compiled my own php cgi and modded my .htaccess to use it...but no joy. http://www.domain.com/test.php still fails. 8(

So it's possibly not my account, but maybe the DH apache user?

Thanks for the suggestion.
I've been racking my brains for an alternative.
Any ideas are VERY welcome!

I cannot use cron jobs as the data crunching needs to be synchonous with the GET HTTP request.
The output of the data crunching is sent back as a http response.

The data being crunched is binary, so an interpreted script language won't cut it.
I chose java, because it is far faster to develop with. (I could do it in C if really needed, but I really, really don't want to add weeks onto this project!).

The actual number of requests for the java crunching will be quite low, so memory and performance is not an issue.

Theres a quote that goes "Premature optimisation is the root of all evil".

By the time you fork the Java app, wait for the VM to start, process the numbers and then return, you may very well have been able to do it in PHP in the same amount of time :)


But you know your app better than i do, so I won't question you!

In reply to:

---

It's probably not PHP, but the account the PHP process is running in...

I logged in using SSH and ran the PHP file that execs java:
php test.php
This worked. The JVM ran and the data was crunched.
If the theory about the PHP memory was correct, then then this should have failed with sme kind of memory exception.

---

Must be an Apache thing then, I bet. Since it runs via command line in PHP. The only difference between the two is Apache.

In reply to:

---

By the time you fork the Java app, wait for the VM to start, process the numbers and then return, you may very well have been able to do it in PHP in the same amount of time :)

---

Ha, I'd have to agree with this statement, too. Java's only really good if you're connecting to a Java server where the VM is running full time. STARTING a Java VM takes ages... ugh

I am having the identical problem doing the identical thing. My PHP script invokes Java. INTERESTINGLY, on one domain (hexaflexagon.com) it works. On the other (omino.com) it doesn't, and I get:

Error occurred during initialization of VM
Could not reserve enough space for code cache

And the main difference I can discern is Apache version. Version 2.0 works for java, aok.

Works: SERVER_SOFTWARE:Apache/2.0.54 (Unix) PHP/4.4.2 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.1.4

Fails: SERVER_SOFTWARE:Apache/1.3.33 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e

One further clue: when I added subversion to hexaflexagon.com, I got some message about how they needed to move the domain to a different server for something about something. I believe SVN requires apache 2.0 for its front end, so that may be a way to "trick" your domain into being apache 2.0 == java compatible. Will investigate...

Here is my findings for the problem of executing a Java program from PHP on Dreamhost using Apache.

Generally, I get these messages:
...
... Error occurred during initialization of VM
... Could not reserve enough space for code cache
...

Even with options like -Xmx10 to try to lower the footprint.

BUT! If I run it on a domain which also has Subversion, everything works! The difference is apache version. Here's a listing from the $_SERVER[] php variables and the output from a php-launched "ulimit -a" from the broken and the working domains.

BROKEN:
... SERVER_SOFTWARE:Apache/1.3.33 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e
... core file size (blocks, -c) 100700
... data seg size (kbytes, -d) 92160
... file size (blocks, -f) unlimited
... max locked memory (kbytes, -l) 92160
... max memory size (kbytes, -m) unlimited
... open files (-n) 1224
... pipe size (512 bytes, -p) 8
... stack size (kbytes, -s) unlimited
... cpu time (seconds, -t) 10000
... max user processes (-u) 5000
... virtual memory (kbytes, -v) 92160

WORKING:
... SERVER_SOFTWARE:Apache/2.0.54 (Unix) PHP/4.4.2 mod_ssl/2.0.54 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.1.4
... core file size (blocks, -c) 100700
... data seg size (kbytes, -d) unlimited
... file size (blocks, -f) unlimited
... max locked memory (kbytes, -l) unlimited
... max memory size (kbytes, -m) unlimited
... open files (-n) 8000
... pipe size (512 bytes, -p) 8
... stack size (kbytes, -s) unlimited
... cpu time (seconds, -t) unlimited
... max user processes (-u) 5000
... virtual memory (kbytes, -v) unlimited

SO. The workaround is to install subversion on your domain. This is coincidental, of course; it is just a quirk of configuration that Java happens to run ok in this situation, and Dreamhost may change the settings at any time which would break it.

Thats pretty interesting. It looks like the apache 2 servers are slightly better deals on some of the other details too. (It's a shame they don't have the gzip mod installed.)

I wonder if DH know about this 'workaround'...ooops! too late. (doh!) Well, unless its official policy, I'm going to have to steer clear, I can't afford to have my site break at the flick of a switch.

This thread is a bit old, but I am experiencing the same problem with the little java program I'm trying to use: "joinPDF". It looks like I'm on an Apache 2 server, but have the problem. Things work just fine from the command prompt... Is running the Java program on a Cron job the only solution for now?