On 10/17/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > In terms of end to end functionality, our use of GZip encoding works fine > > and the encoded representations make it from client to server OK, so the > > concern is simply that there end up being hundreds of these "dead corpse" > > threads left over as our software runs for longer. > > > > As suggested by Tim, I have added an explicit call to setDaemon(false) in > the ByteUtils class, before starting the IO threads. I hope that this can > workaround the issue.
I think it's good practice to setDaemon(false) as you've done -- though I still would like to know *why* the threads in Matthew's example have daemon status -- but I don't think it will solve Matthew's problem, which is that large numbers of permanently blocked threads are accumulating over long server runs. (The only difference between daemon threads and user threads is that the former don't prevent a JVM from exiting.) I can't think of an explanation for the platform-specific behavior, but it appears that somehow the underlying queue is blocking forever on a put. A simple way to avoid this without having to understand why it is happening is to use queue.offer(byte, timeout, unit) instead of queue.put(byte), throwing IOE if offer fails. Pick the timeout to give the input stream consumer ample time to kick in; some number of seconds, say. Then at least these threads will eventually go away. Likewise, on the input stream side you could use queue.poll(timeout, unit) instead of queue.take(), throwing IOE if the poll fails. Again, pick a timeout to give ample time for the representation to be encoded and partly enqueued. A more robust approach might involve using an ExecutorService to execute the writer tasks asynchronously, instead of explicity creating a Thread. But that's a bigger project that should probably wait until Matthew's issue is resolved. --tim
