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]
