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
