[cvsnt] CVS lock server

[Bo Berglund]

>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