Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000377 [Resin] minor always 09-05-05 00:00 11-30-05 14:42
Reporter studdugie View Status public  
Assigned To
Priority immediate Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 3.0.15 Product Version 3.0.14
  Product Build 3.0.14
Summary 0000377: Deadlock in com.caucho.server.log.AccessLog.log
Description RSN-421
There is a nasty little deadlock in com.caucho.server.log.AccessLog.log(HttpServletRequest,HttpServletResponse) starting at AccessLog, line 304. The scenario that triggered it is I've exhausted the ThreadPool servicing TCP request. All those request servicing threads will eventually call AccessLog.flush. So the first thread to get to AccessLog.flush acquires the monitor on the _bufferLock object, it then calls AccessLogWriter.write(AccessLogBuffer). This is were the deadlock begins in ernest. In a previous run <code>if (_writeQueue.size() < _maxQueueLength)</code> and <code>if (! _hasThread)</code> in AccessLogWriter.write is true therefore, <code>_hasThread = true; ThreadPool.schedule(this);</code> got executed. During the deadlock run <code>if (_writeQueue.size() < _maxQueueLength)</code> is false so the thread executes <code>_writeQueue.wait();</code>. Since the Thread pool is exhausted there are no threads ever available to every purge _writeQueue which means the first thread is _waiting_ forever which means it never releases the monitor it acquired on _bufferLock which means all the other threads are stalled forever waiting to acquire _bufferLock's monitor which will never get released because the first thread is _waiting_ forever.

I've attached the Thread dump that aided me in deriving the explanation I've just presented.
Steps To Reproduce
Additional Information Linux
Attached Files

- Relationships

- Notes
(0000435)
ferg
09-05-05 00:00

Instead of wait, calling the flush code directly.
 

- Issue History
Date Modified Username Field Change
09-05-05 00:00 studdugie New Issue
11-30-05 00:00 administrator Fixed in Version  => 3.0.15
11-30-05 14:42 ferg Status resolved => closed


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
29 total queries executed.
27 unique queries executed.
Powered by Mantis Bugtracker