Hi Aaron, Thanks for your help on this one. The reason I suspect a deadlock is twofold:
1. Within Cocoon (which is what's hosting JCS in this case) I have a very rapidly growing data file - it gets to about 300mb within about 30 minutes of operation. After the 20 - 30 minute mark the iowait on my box jumps to 98 - 100% on 2 cpus. It will drop back down again after a while, but will shortly go back to 98 - 100%. This only occurs when using JCS IndexedDiskCache. The only read / write lock being used for the store is the JCS implementation - we've recently removed a legacy r-w lock class. 2. I've seen many mentions of deadlock issues on various postings: http://forum.hibernate.org/viewtopic.php?t=924937 And some others which I consider a bit too inflammatory to be reliable. To be honest, I haven't gotten to the stage of properly debugging where the alleged deadlock is. I'll go through the various logs I can find, one site I read did mention of a potential error in the ReadWriteLock class: /*** 56 * Issue a read lock if there is no outstanding write lock or threads 57 * waiting to get a write lock. Caller of this method must be careful to 58 * avoid synchronizing the calling code so as to avoid deadlock. 59 */ 60 public synchronized void readLock() 61 throws InterruptedException 62 { 63 waitingForReadLock++; 64 while ( writeLockedThread != null ) 65 { 66 log.debug( "readLock wait" ); 67 wait(); 68 log.debug( "wake up from readLock wait" ); 69 } 70 71 log.debug( "readLock acquired" ); 72 73 waitingForReadLock--; 74 outstandingReadLocks++; 75 } You'll notice that in the event of an InterruptedException being thrown, the waitingForReadLoack, and outstandingReadLocks variables will remain unchanged - could this be causing problems? Again, thanks for your help here - I'll get back to log analysis :) -----Original Message----- From: Aaron Smuts [mailto:[EMAIL PROTECTED] Sent: Thursday, 11 March 2004 6:07 a.m. To: [EMAIL PROTECTED] Subject: FW: Deadlock in Indexed Disk Cache There is a shutdown bug, where the keys don't get stored, that I'm going to try and get the fix in tomorrow. However, I've never heard of a deadlock problem. Can you tell me two things: 1. Why do you think there is a locking problem with the indexed disk cache in particular and not somewhere else? That somewhere else should include the possibility of it being outside of JCS. 2. Are you using groups--the element group feature? And can you show me this warning you're talking about. And can you send your cache access code. Thanks, Aaron > -----Original Message----- > From: Corin Moss [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 10, 2004 4:00 AM > To: [EMAIL PROTECTED] > Subject: Deadlock in Indexed Disk Cache > > > Hi Guys, > > Thanks for all the work you've put into JCS, it's one of the best JSR-107 > implementations out there. Its completeness really is amazing :) > > I'm coming up against the deadlock problem within the Index disk cache. I > know several people have found this, but I'm not sure that anyone really > has a definitive answer regarding what causes it. > > I've seen a warning in the readLock method of the ReadWriteLock class > which warns against synchronizing calls, is this where the problem lies? > > I'm experiencing deadlock after about 30mins of heavy(ish) usage. > > I'd really like to continue using JCS, I'm helping with the effort across > at Cocoon - we're investigating JCS as a default store for Cocoon. I just > need to get a slightly better understanding of the issues remaining. > > On another note, has any thought been given to promoting JCS to a jakarta > level project (rather than a child of Turbine)? > > Any feedback on this issue, and the general state of JCS in heavy > production environments would be most appreciated. > > Thanks, > > Corin > > ================================================================ > CAUTION: This e-mail and any attachment(s) contains information that > is intended to be read only by the named recipient(s). It may contain > information that is confidential, proprietary or the subject of legal > privilege. This information is not to be used by any other person > and/or organisation. If you are not the intended recipient, please > advise us immediately and delete this e-mail from your system. Do not > use any information contained in it. > > ================================================================ > For more information on the Television New Zealand Group, visit us > online at http://www.tvnz.co.nz > ================================================================ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ================================================================ CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz ================================================================ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
