This is 3.0.4, right?
We have found some problems with GUID and UID hashcodes what keeps a hashTable taking more time and CPU to process.
If you upgrade to latest 3 version this problem is fixed.
Also you should consider using "cmp2.x jdbc2 pm" container configuration, which is much faster.
thanks for your reply
but why is the JBoss process not using all the CPU's ?
I thought that every session bean is running in its own thread which could be connected to a native OS thread (we are using Sun's JDK 1.4.2_08)
Any application server will have resources shared across multiple threads.
It could be a datasource, a transaction manager.. anything.
On this case this was a synchronization issue. A static resource taking more time than expected causing a synchronization issue.
Whenever you have this problem again, use a kill -3, and that will generate a thread dump. With the thread dump we can verify where is the contention. (it could be even your own contention).
Thanks for the info.
We will do some profiling of the application