Tomcat – Openfire Java Out of Memory Error – Any solutions

I believe you will find that the JVM won't start if you set the memory too high on your system (something like "Could not reserve enough space for object heap")

How many users are you planning to have? If it's just a few, openfire should run alright with 128MB or so. If you are planning to have more than a dozen active at any one time, you really should look into getting more memory in your server. This is doubly true if you're planning to run a database on the same server. You don't want to run Openfire on a server that's running in swap memory.

Another thing - the version of openfire that ships with Debian is probably really old. Get the latest version, or at least 3.5.

Well, let's look at some bigger picture issues before getting into JRun configuration details.

If you're getting java.lang.OutOfMemoryError exceptions in the JRun error log, well, you're out of memory. No upvote for that, please ;-). You didn't say whether you were running 32- or 64-bit Windows, but you did say that you have 8 GB of RAM, so that will have some impact on an answer. Whether or not you're running a 32- or 64-bit JVM (and what version) will also impact things. So those are a few answers that will help us get to the bottom of this.

Regardless, your application IS running out of memory. It's running out of memory for one or more of these reasons:

1. Your application is leaking memory. Some object your application uses is continually referenced and therefore never eligible for garbage collection; or worse- some object created new on every request is referenced by another object in perpetuity and therefore, never eligible for garbage collection. Correct J2EE session handling can be particularly tricky in this regard.
2. The amount of required memory to handle each concurrent request (at the configured concurrent request level) exceeds the amount of memory available in the JVM heap. For instance, you have a heap size of 1 GB and each request can use up to 10 MB. Your app server is tuned to allow 150 concurrent requests. (Simplistic numbers, I know). In that case, you would definitely be running out of memory if you experienced 100 or more concurrent requests under load (if each request used the maximum amount of memory necessary to fulfill the request).

Other things to keep in mind: on 32-bit Windows, a 32-bit JVM can only allocate approximately 1.4 GB of memory. I don't recall off the top of my head if a 32-bit JVM on 64-bit Windows has a limitation less than the theoretical 4 GB max for any 32-bit process.

UPDATED

I read the blog post linked via TalkingTree and the other post linked within that post as well. I haven't run into this exact case, but I did have the following observation: the JRUN metrics logging may not record the "max values" you cited in a period of peak thread usage. I think it logs metrics at a fixed, recurring interval. That's good for showing you smooth, average performance characteristics of your application, but it may not capture JRUN's state right before your error condition begins to occur.

Without knowing about the internal workings of JRUN's thread management, I still say that it really is out of memory. Perhaps it's not out of memory because your app needed to allocate memory on the JVM heap and none was available, but it's out of memory because JRUN tried to create another thread to handle an incoming request and the heap memory necessary to support another thread wasn't available- in other words, threads aren't free- they require heap memory as well.

Your options seem to be as follows:

1. Reduce the amount of memory your application uses in each request, or-
2. Experimentally reduce the value of the thread tuning parameters in JRUN's configuration to make more threads queue up for processing instead of becoming runnable at the same time, or-
3. Reduce the number of simultaneous requests in the ColdFusion administrator (Request Tuning page, field "Maximum number of simultaneous Template requests")

Regardless of the option you pursue, I think a valid fix here is going to be experimental in nature. You're going to have to make a change and see what affect it has on the application. You have a load testing environment, right?