D
dbeavon
Guest
Coincidentally, we just ran into big problems today related to the number of threads that "classic" appserver creates in HP-UX. Our statefree appserver reached 1200 threads and then everything started crashing. According to the kctune command, that appears to have been the limit. There are at least a two related KB articles from Progress. BROKER CRASHES WITH JAVA.LANG.OUTOFMEMORYERROR: UNABLE TO CREATE NEW NATIVE THREAD Progress KB - Stateless AppServer Broker crashes with java.lang.OutOfMemoryError: unable to create new native thread errors HOW TO CONFIGURE MAX_THREAD_PROC AND AVOID JAVA OUT OF MEMORY ERROR ON HP-UX. Progress KB - How to configure max_thread_proc and avoid Java Out of Memory error on HP-UX. According to the KB’s, Progress seems to be aware of the fact that their "classic" appservers use too many threads. It seems to be an extremely bad design decision to hold onto one dedicated thread for every app/user connection. Instead of dedicating threads, most server processes I've worked with are supposed to be designed with thread “pools” that are shared as a common resource for multiple clients. It may sound a bit negative but I seriously doubt that Progress is going to fix this. It's just another great incentive to get their customers buy their other PASOE product as well.
Continue reading...
Continue reading...