The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

import-bot (20211) [Avatar] Offline
#1
[Originally posted by chrishart]

First, kudos on _Bitter EJB_. Great book - it's quickly becoming my bible of
what not to do.

My question: We have a J2EE application running on WebSphere 4.0 that
experiences a locked/run-away thread issue under heavy load. We haven't had
any luck troublshooting it (including working with IBM) and I was hoping you
could provide some insight... The app is fairly evenly divided between
JSPs/servlets and EJBs, almost all of which are stateless. We have both
running in the same JVM (which is load balanced across multiple physical
servers and also vertically scaled on the same multi-CPU Sun box).

The symptom we see is web threads running away - eventually they reach the max
(currently 100), users see HTTP 500's and processing on that container grind
to a halt. If we reduce the load, the container eventually comes back to
life. Even under peak load, the application functions normally for a short
period of time (~15 minutes) with average active web threads hovering around
12/container.

On page 91, you mention separating thread pools for client requests and JMS
messages. I'm not clear on how to implement that (either generally speaking
or specific to IBM WebSphere). Our particular application is very depenendent
both on synchronous JMS messaging and the use of JDBC pools, although we've
been unable to find a specific bottleneck. (Hardware resources are all under
utilized at the time this issue occurs.)

Analyzing thread dumps has been arduous and we've been unsuccessful at
determining the nature of the issue using them. At the load at which this
issue occurs (1000+ users), there are so many threads to look at, it's
difficult to tell the source of the problem. In general terms, what is the
best approach to reducing the set of potential problems?

Any insight is greatly appreciated!

Chris Hart
FleetBoston Financial
Christopher_T_Hart@fleet.com