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 >
