I'm working on setting up a new server in a testing environment and almost everything works, but Java can't seem to create a new process. Short version of the architecture: Windows 2003, IIS6, ColdFusion 8.0.1 MultiServer with JRun, everything is 64-bit*.

A ColdFusion request calls some Java code that runs R (the statistical package) as a native process, captures the resulting stdout/stderr, and does some additional work with it. The Java code doesn't seem to be launching R, although no exceptions are thrown. It runs through everything (through capturing stdout/stderr/exitcode), but it appears the R executable is not invoked, there's nothing in stdout/stderr, and Process.exitValue() returns 128.

I took R out of the equation and just tried to get the code to return the output of "cmd.exe /c dir" and nothing changed -- exitValue() still returns 128. (*I'm using R 2.10.1, which is only 32-bit, but since I can't even run cmd.exe I believe that's not relevant.)

I also believe I've ruled out access/permission issues. The AppPool that ColdFusion uses is set up to run as NetworkService, but I've even tried setting the identity to a domain administrator and it didn't help.

I nearly posted this to StackOverflow (and wouldn't be offended if I'm ultimately redirected there), but this exact same code works in other very similar environments, and this is the only part of our system that doesn't work on the new server.

The other environments where this works:

Win2003, IIS6, CF801 MultiServer, JRun, all 32-bit, testing

Win2008, IIS7, CF801 MultiServer, JRun, all 64-bit, testing

Win2003, IIS6, CF801 MultiServer, JRun, all 64-bit, production

So I guess my questions are as follows:

Has anyone else seen (or better yet fixed) this behavior in a Java server-side app that calls native processes?

Aside from additional logging (which I've tried), what other troubleshooting or diagnostic steps might you try?

1 Answer
1

So we "solved" this by killing a large number of JRun processes. We think the problem is closely related to the issues described here: http://www.arcanadev.com/support/kb/K00000329.aspx, with the process trying to call java's exec being out of available desktop heap space or memory. Very strange.

The other servers where this works properly simply have fewer instances of JRun executing simultaneously. So we believe that our options at this point are (1) have fewer JRun instances running, (2) follow the linked article's advice to increase available desktop heap space, or (3) upgrade to Windows 2008+.