None of this is code we are writing, its all internal to Restlet, all
we are doing is calling EncodeRepresentation.getText() and that
method call causes all the other stuff to happen. I can't see how our
code has any impact on the closing of the stream and shutting down of
the thread.
It also appears that this is not a problem under linux, we will test
under windows, but it may be its a Mac specific thing.
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.
Thanks for your help
Matthew
On 17/10/2007, at 1:16 AM, Tim Peierls wrote:
On 10/16/07, J. Matthew Pryor <[EMAIL PROTECTED]> wrote:
The thread is created by the ByteUtils class in its getStream() method
Yes, but what are you doing with the InputStream returned by
getStream()? I suspect that you aren't reading this stream
completely, so the writing thread blocks forever. The writer thread
is putting things in a capacity-bound queue; it might be better if
the ByteUtils code used timed offer() instead of put().
Independent of the blocking issue, if the thread created by the
call to ByteUtils.getStream isDaemon() without a call to setDaemon
(), that implies that the calling thread isDaemon(). And that's bad.
--tim
