Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
>All this locks are unlocked when client disconnects from the >lockserver. But with large number of directories number of such locks >can be significant (I got about 2 thousand of them with project having >about 300 directories - this is java project so each package is a >separate directory). > >With two concurrent updates on such project number of locks in the >internal lock server list will be 4 thousands and so on. The whole >list is scanned for each lock. > >How this can be solved: > >1. Unlock each file after they are locked. > >2. Use map instead of list in the lock server. > >The best way is to implement both. > >I can modify lock server and test it on windows when I have time. >Should I ? This sounds like there will be a completely different problem soon popping up, if it is not already causing problems. It all depends on how CVSNT server uses the lockserver. AFAICT lockserver is a service communicating over TCP/IP sockets. Then the problem will be this: If CVSNT makes a new connection to the lockserver for each processed directory in order to obtains the lock, then each such call will create two sockets on the server, one for CVSNT and one for Lockserver, to communicate over. This now taxes the Windows TCP/IP handler really hard because there is a limit to the number of active sockets that Windows can handle, something of the order of 3000-4000 sockets. We ran into this problem in an automation system where we connect to a machine tool using sockets. What happenede is that we had an autoconnect feature that would retry the connection every 10 seconds if it was lost or not established. For each such call Windows created a new socket, which was subsequently closed by us after the call failed. But the Windows TCP/IP subsystem *did not* free the closed socket, it kept it lingering on and using up one socket from the available count. After about 10-14 hours of no-connect (the machine was down) we got a Windows exception on the comunication module and we had to shut down the application to clear the socket usage. So we had to revise the autoconnect feature to stop trying after a certain timeout (30 minutes) in order for it not to freeze up the computer. It looks like Windows does not clean out the socket list in a timely manner and therefore runs into the socket count limit. So if CVSNT works in any way like what I believe then simultaneous access to module trees comprising hundreds of folders from different users will potentially bang into the socket count limit.... /Bo