Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the IPC-Locker CPAN distribution.

Report information
The Basics
Id: 49833
Status: resolved
Priority: 0/
Queue: IPC-Locker
People
Owner: Nobody in particular
Requestors: skrisna [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.484

History Show all quoted text
  Sat Sep 19 05:27:26 2009 skrisna [...] gmail.com - 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, Krishna
  Sat Sep 19 07:47:31 2009 wsnyder [...] wsnyder.org - 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_stress
  Sat Sep 19 07:47:33 2009 The RT System itself - Status changed from 'new' to 'open'
  Mon Sep 21 14:43:52 2009 skrisna [...] gmail.com - Correspondence added
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
  Mon Sep 21 14:43:53 2009 skrisna [...] gmail.com - Status changed from 'open' to 'resolved'
  Mon Sep 21 14:44:18 2009 skrisna [...] gmail.com - Status changed from 'resolved' to 'open'
  Mon Sep 21 14:44:34 2009 skrisna [...] gmail.com - Status changed from 'open' to 'resolved'
  Mon Sep 21 19:37:16 2009 wsnyder [...] wsnyder.org - Correspondence added
That's a relief!
  Mon Sep 21 19:37:16 2009 The RT System itself - Status changed from 'resolved' to 'open'
  Mon Sep 21 19:37:49 2009 wsnyder [...] wsnyder.org - Status changed from 'open' to 'resolved'