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]
