: 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
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
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
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
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
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
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
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
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
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
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:
11 matches
Mail list logo