I think it is one of the caches (data, script, ?) and since the tomcat server responds to requests using multiple threads, something needs to synchronize access to the cache bookkeeping, and we chose this oswego library at one point because it was a library of multithreaded synchronization utilities. I haven't looked more closely at this though.
On 1/30/07, Jim Grandy <[EMAIL PROTECTED]> wrote:
Why do we have this code in our server, again? On Jan 30, 2007, at 7:18 PM, Henry Minsky wrote: General rule of thumb: avoid multithreading at all costs. On 1/30/07, Jim Grandy <[EMAIL PROTECTED] > wrote: > > Although, for an "uh-oh" moment on the prospects of JSR166 in Java5, > read > > http://www.nabble.com/Any-fix-for-bug-6460501:- > AbstractQueuedSynchronizer$Node-memory-leak-in-BlockingQueues- > t2739023.html > > jim > > On Jan 30, 2007, at 7:04 PM, Jim Grandy wrote: > > > I think the Oswego ReentrantLock stuff was rolled into Java5. > > Here's a slashdot comment I had to pull out of Google's cache: > > > > http://developers.slashdot.org/comments.pl?sid=130484&cid=10888343 > > > >> > >> JSR166 [jcp.org], the specification implemented in JDK 5.0, is > >> essentially an improved, cleaned-up version of Doug Lea's > >> [oswego.edu] public-domain util.concurrent package, a set of > >> pattern-based building blocks for concurrent programming that have > >> been very popular; Doug Lea himself is the specification lead on > >> JSR166. > >> > >> The util.concurrent package has been very popular among open- > >> source projects, and is known for its strong performance. In many > >> cases, migrating from util.concurrent should be as simple as > >> importing java.util.concurrent.class instead of > >> EDU.oswego.cs.dl.util.concurrent.class . > >> > >> Of course, one of the improvements made by JSR166 is to genericize > >> all the interfaces and classes, so what uses to be a BlockingQueue > >> is now a type-safe, parameterizable class BlockingQueue<E>. > >> > >> Not all of the toolkit made it into the 5.0 release in time, and > >> the missing stuff, referred to as jsr166x [oswego.edu], which > >> comprises "concurrent sorted maps and sets, as well as concurrent > >> double-ended queues (deques)", is available for use. > >> > >> Doug also offers a JSR166 maintenance update [oswego.edu] that > >> fixed a bug in one of the classes. > > > > > > On Jan 30, 2007, at 12:01 PM, P T Withington wrote: > > > >> My current source is trunk -r3598 > >> > >> On 2007-01-30, at 14:33 EST, Benjamin Shine wrote: > >> > >>> In your current source, what is on these lines? > >>>>>> org.openlaszlo.cache.Cache$Item.<init>(Cache.java:898) > >> > >> mLock = new ReentrantLock(); > >> > >>>>> > org.openlaszlo.cache.Cache.findItem(Cache.java:259) > >> > >> item = new Item(key, enc, hasMemCache); > >> > >>>>> > org.openlaszlo.cm.CompilationManager.getItem > >> > >> Item item = findItem(key, enc, lockit); > >> > >>>>> > (CompilationManager.java:610) > >> > >> Eric has left this interesting note: > >> > >> // TODO: [2003-09-04 bloch] > >> // Note: this now only happens when doLockAndLeaveActive is > >> // false. At some point we could rearchitect to remove > >> // this wart > >> > >> I don't have time to dig any deeper at this point, but clearly I > >> tripped on the wart. > >> > >>> (Hooray for line-by-line debugging information! I think pga > >>> turned this on.) > >>> > >>> On Jan 30, 2007, at 11:22 AM, P T Withington wrote: > >>> > >>>> Me either. It has something to do with the cache. My suspicion > >>>> is that something is getting serialized that does not > >>>> unserialize in a later verison or some such which takes the code > >>>> down some path it normally never hits. > >>>> > >>>> I did various rounds of stop/clean/build/start/install combined > >>>> with actually rm -rf of the webapp dir from tomcat and it > >>>> finally stopped. > >>>> > >>>> On 2007-01-30, at 14:06 EST, Henry Minsky wrote: > >>>> > >>>>> I have never figured out what causes that, it seems to persist > >>>>> across server > >>>>> restarts, maybe a file lock, I thought it was only Winblows > >>>>> that suffered > >>>>> from this though. > >>>>> > >>>>> > >>>>> On 1/30/07, P T Withington <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> Well with several hits of the cache cleaning hammer, I seem to > >>>>>> have > >>>>>> solve this. > >>>>>> > >>>>>> On 2007-01-30, at 13:45 EST, P T Withington wrote: > >>>>>> > >>>>>> > I am getting this when I try to load any app from my trunk > >>>>>> > sandbox. I have never understood what causes this error or > >>>>>> how to > >>>>>> > cure it. Any hints? > >>>>>> > > >>>>>> > java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/ > >>>>>> concurrent/ > >>>>>> > ReentrantLock > >>>>>> > org.openlaszlo.cache.Cache$Item.<init>( Cache.java:898) > >>>>>> > org.openlaszlo.cache.Cache.findItem(Cache.java:259) > >>>>>> > org.openlaszlo.cm.CompilationManager.getItem > >>>>>> > ( CompilationManager.java:610) > >>>>>> > org.openlaszlo.cm.CompilationManager.getLastModified > >>>>>> > (CompilationManager.java:594) > >>>>>> > > >>>>>> org.openlaszlo.servlets.responders.ResponderCompile.getLastModifi > >>>>>> ed > >>>>>> > (ResponderCompile.java:394) > >>>>>> > > >>>>>> org.openlaszlo.servlets.responders.ResponderCompile.respondImpl > >>>>>> > (ResponderCompile.java:178) > >>>>>> > org.openlaszlo.servlets.responders.Responder.respond > >>>>>> > (Responder.java:260) > >>>>>> > org.openlaszlo.servlets.LZServlet._doGet > >>>>>> (LZServlet.java:441) > >>>>>> > org.openlaszlo.servlets.LZServlet.doGet(LZServlet.java: > >>>>>> 355) > >>>>>> > javax.servlet.http.HttpServlet.service > >>>>>> (HttpServlet.java:689) > >>>>>> > javax.servlet.http.HttpServlet.service > >>>>>> ( HttpServlet.java:802) > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Henry Minsky > >>>>> Software Architect > >>>>> [EMAIL PROTECTED] > >>>> > >>> > >>> Benjamin Shine > >>> Software Engineer, Open Laszlo / Laszlo Systems > >>> [EMAIL PROTECTED] > >>> > >>> > >>> > >> > > > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
