Bad Thread management (and URL decoding)

[J.H.B. Oosterlaar]

Hi,
We just found out that Thread management and URL decoding don't go hand in hand.
What is the setup?
A Servlet enqueue requestinformation (such as the referrer-url) as a JavaBean. A concurrent Thread dequeues the beans and processes the contained information including the decoding of the referrer-url.
What is the critical situation?
The refferer-url can be NULL. The decoding of a NULL value, does not throw an fatal exception. Only when catching all exceptions, an exception is caught about the NULL value. But again, there is not fatal exception.
What are the consequences?
When this happens within the Thread, the Thread is simply being killed. Without any exception or other notice. The buffer keeps growing and growing, because of the fact that the dequeueing Thread doesn't exsist anymore.
Do you know why this happens? I really don't get it. It doesn't make sense, or does it?
Thanks in advance.
Cheers,
Jeroen

[Peter den Haan]

Originally posted by J.H.B. Oosterlaar:
[...] When this happens within the Thread, the Thread is simply being killed. Without any exception or other notice. [...]

I don't believe you. Some type of Throwable is being thrown and allowed to propagate outside Thread.run(). As soon as the run() method returns for whatever reason, a Thread will terminate.
The Throwable will be either an Error or a RuntimeException. Errors you should generally catch, log, and re-throw. RuntimeExceptions are more ambiguous. Sometimes (when executing client code of unknown quality) it is appropriate to catch, log, but otherwise ignore RuntimeExceptions inside your processing loop, much like an application server would do with an exception thrown in, say, a JSP. Sometimes it's appropriate to re-throw the RuntimeException after logging it. It depends on your application. But even when you re-throw the exception and thereby terminate your consumer thread you can still implement logic to start up a replacement consumer or do whatever recovery is appropriate.
- Peter
[ April 08, 2003: Message edited by: Peter den Haan ]