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: 49888
Status: open
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: (no value)

History Show all quoted text
  Mon Sep 21 15:51:39 2009 skrisna [...] gmail.com - Ticket created
I describe a recent issue we had when working with IPC::Locker 1.484 which could be an issue with the IPC::Locker module itself or with something else. When working with a large number of simultaneous connections to the server this is a problem we encountered- 1. The client tries to open a new lock and talks to the server. 2. The server creates a new lock but that information is either not sent back to the the client or gets lost somewhere. 3. The client assumes that the lock was not created, and since we didn't block while seeking new locks, the IPC::Locker client returns an undef to the caller program. I have a lot of log files to prove that the lock was created in the server but this information was not transmitted to the client. This problem occurs very rarely and only when there are too many connections to the server. If this is a known problem in such scenarios, then is there a way out? Thanks, Krishna
  Mon Sep 21 19:40:04 2009 wsnyder [...] wsnyder.org - Correspondence added
Is this also resolved?
  Mon Sep 21 19:40:05 2009 The RT System itself - Status changed from 'new' to 'open'
  Mon Sep 21 22:22:38 2009 skrisna [...] gmail.com - Correspondence added
No. This is not resolved. This is most definitely an issue -- but I not sure whether it is an issue with IPC::Locker or with IO::Socket. I can prove it using collected log files that there are some communication problems between the server and client in some cases.