Apologies I have been travelling but greatly appreciate the attention
& resolution from all involved.
Best,
jmp
On 19/10/2007, at 4:33 AM, Jerome Louvel wrote:
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
À : [email protected]
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
