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 Pryor wrote:
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 with the representation's content.
*/
public static InputStream getStream(final Representation
representation)
throws IOException {
if (representation != null) {
final PipeStream pipe = new PipeStream();
// Creates a thread that will handle the task of continuously
// writing the representation into the input side of the pipe
Thread writer = new Thread() {
public void run() {
try {
OutputStream os = pipe.getOutputStream();
representation.write(os);
os.write(-1);
os.close();
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
};
// Starts the writer thread
writer.start();
return pipe.getInputStream();
} else {
return null;
}
}
The problem is that at least on my Mac OSX running Java 5, the above
call to representation.write(os) blocks at this line
encoderOutputStream.finish(); in the method below
/**
* Writes the representation to a byte stream.
*
* @param outputStream
* The output stream.
*/
public void write(OutputStream outputStream) throws IOException {
if (canEncode()) {
DeflaterOutputStream encoderOutputStream = null;
if (this.encoding.equals(Encoding.GZIP)) {
encoderOutputStream = new GZIPOutputStream(outputStream);
} else if (this.encoding.equals(Encoding.DEFLATE)) {
encoderOutputStream = new
DeflaterOutputStream(outputStream);
} else if (this.encoding.equals(Encoding.ZIP)) {
encoderOutputStream = new ZipOutputStream(outputStream);
} else if (this.encoding.equals(Encoding.IDENTITY)) {
// Encoder unecessary for identity encoding
}
if (encoderOutputStream != null) {
getWrappedRepresentation().write(encoderOutputStream);
encoderOutputStream.finish();
} else {
getWrappedRepresentation().write(outputStream);
}
} else {
getWrappedRepresentation().write(outputStream);
}
}
On 16/10/2007, at 11:05 PM, Tim Peierls wrote:
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
with daemon threads is a bad idea. To quote from Java Concurrency in
Practice:
Daemon threads should be used sparingly -- few processing activities
can be safely abandoned at any time with no cleanup. In particular, it
is dangerous to use daemon threads for tasks that might perform any
sort of I/O. Daemon threads are best saved for "housekeeping" tasks,
such as a background thread that periodically removes expired entries
from an in-memory cache. Daemon threads are not a good substitute for
properly managing the life-cycle of services within an application.
--tim
On 10/15/07, J. Matthew Pryor < [EMAIL PROTECTED]> wrote: 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: 1767
ArrayBlockingQueue<E>.put(E) line: 368
ByteUtils$PipeStream$2.write(int) line: 331
ByteUtils$PipeStream$2(OutputStream).write(byte[], int, int)
line: 99
GZIPOutputStream.finish() line: 91 [local variables unavailable]
EncodeRepresentation.write(OutputStream) line: 235
ByteUtils$2.run() line: 133
We are using EncodeRepresentation and the POST of our resources if
working fine, not sure why these threads are staying around
Thanks,
Matthew