We recently experienced regular java.lang.OutOfMemoryError exceptions on HP/UX any time our J2EE application came under significant load. We have since determined that it is due to a native issue with threading.
The HP/UX kernel has a parameter named max_thread_proc, which sets the maximum number of threads that a process can have. Apparently the default is 64. Considering that JBoss starts up with almost 60 threads when it’s doing nothing, this cap of 64 is quite low.
There are 2 options to fix the problem. One is to pass the -green parameter to the JVM when you start your app server. This causes the JVM to use its own green threading model rather than that of the operating system. The advantage of this approach is that it can be tested and implemented quickly. The disadvantage is that Java’s green threading model isn’t as sophisticated as the native threading model of the underlying operating system (Sun has said as much), so you may pay a performance penalty for this.
The other option is to recompile the HP/UX kernel with a higher max_thread_proc value. We set it to 3000, just to be safe, although we haven’t exceeded 250 yet. The biggest disadvantage to this is that you have to recompile the kernel. The other disadvantage is that you haven’t completely avoided the problem, you’ve only moved the threshold at which it will occur. The advantage is that you get the performance, monitoring, and tuning of using the native thread model.
I don’t think that Linux users need to worry. I believe that Linux’s threading model is native green threading. Note that this is still different from the JVM’s green threading, so -green should still not be used in this case either – Linux will handle it for you.