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: [email protected] > 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]
