RE: found 3.3-head thread problem

[Keith Wannamaker]

This is why-- in PoolThreadEndpoint, a new thread is 
started only when a socket is accepted.  Since the npe
happened  before this, the whole thing shut down without
running another thread.

So, we need to wrap for Throwable, and I think the best
place to do it is around the accept in PTE.runIt.  I'll
add it right now..

Keith


| Great finding. 
| 
| I would also add another round of try/catch for Throwable 
| to catch any other NPE in the catch().
| 
| Not sure about the logic - it is supposed to detect and start
| new threads... If you can take a look...
| 
| Costin
| 
| 
| --
| To unsubscribe, e-mail:   
| For additional commands, e-mail: 
| 
| 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: found 3.3-head thread problem

[costinm]

On Wed, 15 May 2002, Keith Wannamaker wrote:

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

Great finding. 

I would also add another round of try/catch for Throwable 
to catch any other NPE in the catch().

Not sure about the logic - it is supposed to detect and start
new threads... If you can take a look...

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: