Hi Tim, Thanks again for the suggestion about the queue. That makes total sense. I've just applied the changes to SVN.
Best regards, Jerome > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la > part de Tim Peierls > Envoyé : mercredi 17 octobre 2007 23:41 > À : discuss@restlet.tigris.org > Objet : Re: EncodeRepresentation.write leaving blocked threads around? > > 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 > >
