Ralph Goers wrote: > We finally got some thread dumps from our production server. It shows > something very different than what we were seeing in testing. First, > this happens under light load after running for days. To summarize, > many threads are waiting for the ResourceLimitingPool and several are > waiting for the class loader. This system hasn't had the pools tuned so > I'm not surprised about pool contention, but I don't believe that is the > issue. That is because the thread holding the lock is simply waiting for > the class loader. > > We took two traces and both were similar, but not identical. Different > threads were holding the class loader lock in both. However, in both > cases the threads holding the class loader lock were called from Castor > while creating the portal layout. > > So far, we have been speculating that the problem is due to a problem > with the NPTL threads on Enterprise Linux 3. However, I'm wondering if > perhaps castor is having problems and simply calling the class loader > over and over. > > I'd appreciate any ideas. > Someone told me some months ago that they experienced several strange issues with castor under load - I think he mentioned class loading and synchronization problems. I still can't remember *who* it was :( So, chances are that this is really caused somehow by castor. I improved the the castor portal implementation for 2.1.8 slightly - the version in 2.1.7 parsed the mapping each time a profile is loaded. I guess that through this operation the classes are loaded as well. In 2.1.8 the mapping is only read once on startup. So my suggestion is to use the CastorSourceConverter from 2.1.8 in your 2.1.7 environment and see what happens.
Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
