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]>