RE: EncodeRepresentation.write leaving blocked threads around?

2007-10-18 Thread Jerome Louvel
: 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

RE: EncodeRepresentation.write leaving blocked threads around?

2007-10-17 Thread Jerome Louvel
Hi Matthew, 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

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-17 Thread Jim Alateras
Jerome Louvel wrote: Hi Matthew, 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

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-17 Thread Tim Peierls
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

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-17 Thread Jim Alateras
Tim Peierls wrote: On 10/17/07, *Jerome Louvel* [EMAIL PROTECTED] mailto:[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

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread Tim Peierls
In this case, as with a subsequent message from Jim Alateras, the problem appears to be that the representation size exceeds the capacity of the underlying pipe (1024), and no one is reading from the input stream side of the pipe. But who made these daemon threads? Mixing blocking data structures

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread J. Matthew Pryor
The thread is created by the ByteUtils class in its getStream() method /** * Returns an input stream based on the given representation's content and * its write(OutputStream) method. Internally, it uses a writer thread and a * pipe stream. * * @return A stream

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread Tim Peierls
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

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread Jim Alateras
Matt, Interesting to see whether we get the same problem on Linux or whether it is specific to the mac. On windows, at least, i don't see any of these threads. You said in the email that the post actually completes but the thread doesn't terminate. Is this correct? cheers /jima J. Matthew

Re: EncodeRepresentation.write leaving blocked threads around?

2007-10-16 Thread J. Matthew Pryor
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

EncodeRepresentation.write leaving blocked threads around?

2007-10-15 Thread J. Matthew Pryor
My running app has about 15 threads this stack traces identical to this? Daemon Thread [Thread-44] (Suspended) Unsafe.park(boolean, long) line: not available [native method] LockSupport.park() line: 118 AbstractQueuedSynchronizer$ConditionObject.await() line: