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]
