Remember last week when I mentioned the thread problem in 3.3-head?

In PoolTcpEndpoint, when there is a SocketException, we log a
non-fatal error message.  The problem began when Remy pointed
the string manager to an empty bundle.  StringManager.getString
will return a null rather than throw a missing resource, and a
null check is not done by JDK 1.3 prior to trying to format the
message.  The resulting npe terminated the thread.  Gradually
over time, all accepting threads are terminated.

So, no big deal, add the missing resources, but I'm wondering, 
why don't we check to see if our accepting thread count dwindles
or vanishes, and start more up?  Is this logic non-existant or broken?

Keith


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to