21/07 11:43:02 error Too many open files
java.net.SocketException: Too many open files
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
        at java.net.ServerSocket.implAccept(ServerSocket.java:453)
        at java.net.ServerSocket.accept(ServerSocket.java:421)
        at jrun.servlet.network.NetworkService.accept(NetworkService.java:356)
        at jrun.servlet.jrpp.JRunProxyService.accept(JRunProxyService.java:103)
        at jrun.servlet.jrpp.JRunProxyService.createRunnable(JRunProxyService.java:119)
        at jrunx.scheduler.ThreadPool$ThreadThrottle.createRunnable(ThreadPool.java:349)
        at jrunx.scheduler.WorkerThread.run(WorkerThread.java:62)

If you know where to look, this may be easily resolved. The maximum number of open files for a certain user can be displayed and set with the ulimit -n command. There is a hard and a soft limit. The soft limit is the one currently set for the user with ulimit -n xxx, the hard limit is the max. number the user can actually set his soft limit to with the ulimit -n command. The hard limit can be displayed with ulimit -Hn.

First thing we do is edit our ColdFusion init-script (mine is /etc/init.d/coldfusion8multi) and add the following line somewhere before the actual start of jrun:

ulimit -n `ulimit -Hn`

Don't restart ColdFusion just yet as most likely both your soft and hard limits are set to 1024 - and this not being high enough is the actual reason for our problem.

You'll need to edit /etc/security/limits.conf next in order to alter the soft and hard limits. If you just want to increase the filehandle-limits for all accounts on this box, the following two lines would be sufficient:

*                soft    nofile          1024
*                hard    nofile          8192

If you just want to set it for the jrun account, replace the wildcard with the account-name. Settings for groups can be done using the @group syntax. The file is fairly well documented inside on most standard installs, so no worries. The changes in this file affect all new logins (or newly started processes), so your running processes are not affected, but after a restart, ColdFusion will have picked up the changes.

There's one issue remaining - the total number of open files for the system has a limit, too. To show the current limit, you can use cat /proc/sys/fs/file-max. You could also write to that pseudo-file in order to increase the limit, but your changes would be lost on system reboot. In order to make your settings permanent, you'll need to edit /etc/sysctl.conf. Add a line like

fs.file-max = 275140

Do a sysctl -p /etc/sysctl.conf for the changes to take effect.

I recently stumbled over an issue when using symbolic links on a couple of ColdFusion applications. I intended to use symlinks to keep duplicate code between different applications to a minimum. I'm running Apache 2.2 with ColdFusion 8.0.1 on 64-bit Debian Etch. Each of our web-applications needs a "connector" while retaining an include with some site-specific config.

This is the intended directory layout

../foo/shared/connector/bar.cfm
../foo/mysite/myinclude.inc
../foo/mysite/connector symbolic link to -> ../shared/connector
../foo/mysite/bar.cfm symbolic link to -> connector/bar.cfm

../foo/mysite/ would be the web-root for my application. bar.cfm just reads <cfinclude template="./myinclude.inc">, myinclude.cfm reads <cfoutput>#now()#</cfoutput>.

Calling http://mysite/bar.cfm I get an error "Could not find the included template ./myinclude.inc." and a detail: "The error occurred in /var/www/.../foo/shared/connector/bar.cfm: line 1". Notice the path to the file that throws the error? ColdFusion seems to have resolved the symlink to its destination instead of executing the symlink in the location it was found just like it would have executed a physical file.

The webserver has no problem with calling this file via symbolik link - if I simply rename the symlink bar.cfm to bar.txt, I get the source code of bar.cfm (as this is not going through ColdFusion). And if I simply copy the physical bar.cfm over the symlink, all is well, too.

Webserver aliases wouldn't work in this case either, because they wouldn't parse the site's Application.cfc, as it's a different physical path. Symlinks would emulate the physical paths being present in different locations, though without actually having several physical copies. Symlinks would be extremely useful - if only they worked as intended (i.e. transparent, as they are for almost any other program). This is exactly the use case symlinks were made for - and the way they are handled by the filesystem.

I wonder what may be the reasoning behind this non-standard link-resolving of ColdFusion. Has anybody else experienced this unexpected behaviour and found some solution?