This bug was cloned from Perl-RT, rt49833.
Email addresses have have been truncated.
Id: 49833 Status: open Queue: IPC-Locker Fixed in: 1.484 Requestors: skrisna <skrisna@> X Attachments locker_stress Created: Sat Sep 19 05:27:21 2009 Last Contact: Sat Sep 19 07:47:33 2009 Closed: Not set Updated: Sat Sep 19 07:47:33 2009 by WSNYDERSat Sep 19 05:27:26 2009 skrisna - Ticket created
Subject: Locking issues We, at BBN Technologies, have been toying with IPC::Locker to solve pretty massive network concurrency issues. Upon using it for a while, we found that the server/client works fine for the most part. But at times, some clients get stalled forever. We have not been able to debug this problem but here is what we found- If there are a lot (400+ clients) trying to talk to the server at the same time asking for different locks, and if three or more clients ask for the same lock at the same time and are setup to be blocking, then this is what happens: Lets say A,B,C are three clients requesting the same lock at the same time. The server serves A and puts B and C into waiting. Once A is finished with the lock, it serves B with the same lock. In the meantime, client D also requests the same lock from the server. After B, the server serves D with the lock but forgets to ever serve C. So C goings into infinite wait and stalls. I haven't had a chance to look at the server code but will try doing some debugging at our end to resolve this issue. Thanks, KrishnaSat Sep 19 07:47:31 2009 WSNYDER - Correspondence added
Sorry you are having problems. I've been using it on 500ish node clumps (with a few larger test runs) and haven't seen this issue, but I'm not sure I'd notice unfairness; I would notice giving locks to multiple people though as we unfortunately had that problem at one point in development. I've attached a program to stress out the locker from one multi-cpu machine. I then run this on many machines in parallel (manually). Unfortunately it may not check for your problem, nor can it check other than between threads that there's multiple owners of the lock (as this would require a different lock mechanism). Now that I think of it, maybe I should have the stress talk to two daemons, then it could use the second to check that no one else has the lock. Anyhow, let me know if you find the issue. Subject: locker_stressSat Sep 19 07:47:33 2009 RT_System - Status changed from 'new' to 'open'
Subject: [rt.cpan.org #49833] Locking issues RT-Ticket: rt.cpan.org #49833 Managed-by: RT 3.6.HEAD (http://www.bestpractical.com/rt/) Date: Mon, 21 Sep 2009 14:43:53 -0400 Queue: IPC-Locker Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49833 > I found the problem - it had nothing to do with IPC::Locker. My locking system needed me to generate unique user ids everytime I ran it. and I was using srand(time ^ $$ ^ unpack "%L*", `ps axww | gzip`); to initialize the random number generator. By some strange chance, this was producing the same random number when I used rand(100000000); for two distinct processes. I am closing this ticket. Thanks, Krishna
Also available in: Atom