Re: Re: Deadlock in oscache 2.0

Hi Chris,

Yeah, I loaded the latest CVS and repackaged oscache 2.0 with the latest
Cache.class which appears to have contained the deadlock fixes and the
only class to contain code changes since 2.0.  However, I can still
reproduce the deadlock on my system, as it appears that it only takes one
thread to cause the hang.  I'll see if I can work up a test case.  Below
is the stack trace.

"Thread-29" daemon prio=1 tid=0x0843bd58 nid=0x1281 in Object.wait()
[bafff000..bafffb6c]
  at java.lang.Object.wait(Native Method)
  - waiting on <0x449a0000> (a
com.opensymphony.oscache.base.EntryUpdateState)
  at java.lang.Object.wait(Object.java:429)
  at com.opensymphony.oscache.base.Cache.getFromCache(Cache.java:238)
  - locked <0x449a0000> (a com.opensymphony.oscache.base.EntryUpdateState)
  at com.opensymphony.oscache.base.Cache.getFromCache(Cache.java:183)
  at
com.opensymphony.oscache.general.GeneralCacheAdministrator.getFromCache(GeneralCacheAdministrator.java:128)

-Dave

On Sat, October 18, 2003 1at 1:06 am, Chris Miller sent the following
> I checked in a fix for a deadlock problem a couple of days ago. The only
> time it occurs is when there are more than two threads waiting on a new
> cache entry to be built, AND you call cancelUpdate(). So give the current
> CVS head a try, if that still doesn't solve the problem then file a Jira
> issue and I'll investigate further. If you still see deadlocks then a test
> case would be very helpful in tracking down the problem.
>
> (As an aside, there was a nasty threading problem in 1.7.5 that caused a
> memory leak and gradual performance degradation, bear that in mind if you
> roll back to 1.7.5 in the meantime).
>
> Chris



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com