Re: Thread deadlock in CacheEventQueue class

[Hanson Char]

Or other Concurrent* collections for that matter (ie iteration on an
active collection)

On Fri, 14 Jan 2005 17:07:01 +1100, Hanson Char <[EMAIL PROTECTED]> wrote:
> Ever consider using the jsr166 ConcurrentNavigableMap and
> ConcurrentSkipListMap ?
> 
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166xdocs/jsr166x/ConcurrentNavigableMap.html
> 
> H
> 
> On Thu, 13 Jan 2005 21:48:05 -0800, Aaron Smuts <[EMAIL PROTECTED]> wrote:
> > I suspect that it was the remove / put problem that I solved in 1.1.2.
> > It was the only known problem of that sort.  It may be due to iteration
> > but I thought this was resolved.  Iteration is very problematic on an
> > active collection.  There is no really good way to do it.  We basically
> > copy the keys in fail fast mode.  Were you seeing unrecoverable deadlock
> > or just temporary lags?
> >
> > I'll try some more strenuous testing.  The big problem is that it is
> > very difficult to create automated tests for the remote and lateral
> > caches.  I mainly rely on the tester script.  I have a random function
> > that will beat the hell out of the cache. . . . .
> >
> > Aaron
> >
> > > -----Original Message-----
> > > From: Matthew Cooke [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, January 11, 2005 8:52 AM
> > > To: turbine-jcs-user@jakarta.apache.org
> > > Subject: RE: Thread deadlock in CacheEventQueue class
> > >
> > > We had major problems when we used the remotecache configuration in
> > push
> > > mode rather than delete mode (removeOnPut).
> > >
> > > At the time we strongly suspected a deadlock caused by the local puts
> > > placing cached items back into the local memory caches when they
> > > recieved async put events from the remotecache.
> > >
> > > Could the deadlock we were seeing when using remotePuts have been the
> > > same thing? We are quite keen to try remotePuts again as this
> > > functionality would be very useful to us (would allow iteration over
> > > whole caches on individual machines). As the deadlock was only
> > occuring
> > > under high load we don't have a reliable way to test.
> > >
> > > Any advice appreciated!
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]