Mailing-List: contact turbine-jcs-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Turbine JCS Users List" <turbine-jcs-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of hanson.char@gmail.com
 designates 64.233.184.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=RvZ6MTU71AKSnr+y9Oi4qvEeY4+EI+b9XkkJaOexWdfC40ikEBNy+emH4SUokkiwdaKET/8wtVnlUJ/UTtC7yioNgBvWCgFtiqYGgeR9XDzl8hHG6VBAVSEEeDK39LzQPLcXn1gVck/t3L+EtYGjcCzyaTDjzup9/85kULHh9fA=
Message-ID: <ca53c8f80501132210745ab08d@mail.gmail.com>
Date: Fri, 14 Jan 2005 17:10:19 +1100
From: Hanson Char <hanson.char@gmail.com>
Reply-To: Hanson Char <hanson.char@gmail.com>
To: Turbine JCS Users List <turbine-jcs-user@jakarta.apache.org>
Subject: Re: Thread deadlock in CacheEventQueue class
In-Reply-To: <ca53c8f805011322077fc11f4@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41E40422.5060900@connextra.com>
	 <001101c4f9fc$9ea62560$6401a8c0@smuts>
	 <ca53c8f805011322077fc11f4@mail.gmail.com>

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

On Fri, 14 Jan 2005 17:07:01 +1100, Hanson Char <hanson.char@gmail.com> 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 <aasmuts@wisc.edu> 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:matthew@connextra.com]
> > > 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:
> > turbine-jcs-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-jcs-user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org