Perforce api leaves idle connections open

[Rinn]

I mentioned this when some ATF guys came to our studio, but posting for visibility.

The Perforce api in ATF doesn't close connections after it is finished with them, and leaves a large number of idle server connections open. In one case we saw a single user that had 7500 idle processes persisting from an ATF tool and our IT department has been asking if this can get resolved.

Additionally the api should be passing in the ProgramName option when creating the connection so 'p4 monitor show' will show the actual application name instead of dot-net-api-p4.

[Ron2]

Hi Joseph,

Thank you for creating the issue tracker and for providing more details (7500 idle processes on the P4 server!?!). I had shared your feedback with the rest of the ATF team from our meeting but had not found anyone to look into this yet and I didn't appreciate the seriousness of it.

I looked into why another client who has used our PerforceService for years had not complained and it looks like their older version was doing the right thing of using try-finally on each command to open and close P4 connections. The problem apparently came when we integrated changes from another tools team, which, as I recall, was to avoid blocking the GUI when the P4 connection was slow.

Anyway, I'm looking into this now. Thanks again for reporting this.

--Ron

[Ron2]

Hi Joseph, I installed the latest Perforce server on my Windows 7 laptop, and I tested our Code Editor sample app with this local server. I can check out files, revert changes, etc. I have not yet been able to reproduce the problem.

Are you using the Windows version of Perforce server or the Unix version?

I did find that when the ATF app is shut down, that Dispose() was not being called on the Perforce.P4.Connection. I don't think this could be the cause of your problems, though, because presumably your app isn't being started and shut down hundreds or thousands of times a day and even so, I don't see any additional threads showing up when I run the "p4 monitor show" command.

If you wanted to test this, you could add this finalizer to our ConnectionManager class:

        ~ConnectionManager()
        {
            Dispose();
        }

I'm still investigating. I've asked our IT department and they've reported this problem of too many processes on a "newer Perforce edge server" but that they don't have this problem on older Perforce servers. I'll try to reproduce this problem with them and also put in a valid app name instead of the default "dot-net-api-p4".

--Ron

[Rinn]

Ron I'll email you the detailed specs. The short of it is that we are running a newer unix version of the server,

[Ron2]

I checked in an updated P4API.NET library last night that might have fixed the problem. See my check-in notes above.

--Ron

[Rinn]

I'll give it a try, I may not have results back until after the new year because we're about to go on holiday.