Check in Folder takes a long time

[rshillington]

Using Version 2.0.0 (2120)

Throughout the day, I have to check out a folder of about 166 files. I use the vault client and the check out happens fast enough (about 5 seconds)

I then run a my code generator which will re-write all 166 files, ususally leaving the final content exactly the same, but with a certain number of files updated.

I then check in the folder, using the vault client, and here's where the slow down happens. It seems to undo the check out on all the files that have not changed and check in the few files that have changed. This process takes about 5 seonds per file (according to the messages pain)

Is it acutally doing a diff of my local file to the repository to determine if a check-in or undo check-out is required?

Is there anything that I can do to speed up this process.

[dan]

This is a known problem that will be fixed in an upcoming 2.0.3 release.

It does check to see whether a file has actually been modified before it checks it in, so it can do an Undo checkout if your option is set that way. What takes so long, though, is that it performs each undo checkout separately, rather than undoing them all at once.

[sterwill]

The undo check out durring commit/check in is slow in all versions of Vault previous to 2.0.3 because of a bug where the client requests an updated check out list after each one. 2.0.3 will be released soon. Until then, if you know which files aren't really changed, you can undo them manually (or not select them for check in). You could also change your Vault option "Check in unchanged files" to be "Check in" instead of "Undo check out". This will create new versions in the repository for the unmodified files, and skip the undo process.

[pfoley]

I also have been experiencing slowdowns that could be perceived as hangs - except I see network activity. Is that related?

Frequently when I attempt to get by label, Vault will slow to a crawl (with no UI feedback). Sometimes only rebooting will solve the problem. Is this a known bug that 2.0.3 addresses?

[sterwill]

Get by label would be unaffected by the "undo checkout during commit" bug. Is there any network activity during your "hang?" Is the server's CPU usage high during this period?

[pfoley]

Get by label would be unaffected by the "undo checkout during commit" bug. Is there any network activity during your "hang?" Is the server's CPU usage high during this period?

Slight network activity - very low CPU usage

[pfoley]

sometimes "hangs" when doing show labels, sometimes during get by label before the confirmation dialog and sometimes after the confirmation dialog.

[sterwill]

Is your connection to the server on a fast or slow link? If the CPU usage on the client is also low (as it should be, since it's just waiting on the server) you might try turning on debug logging on the Vault server, in order to see which web methods are taking a long time to execute. To do this, edit the Vault.config file where the web service is installed, and change the "LogLevel" setting's value to "Debug" (from its usual "Quiet"). Then run "iisreset" on the server. Now the Vault server log will include more details about which methods are called.

[Guest]

Fast (local)

I'll add the line to Vault.config.

Can you tell me where the Vault server log is located? Is there documentation that explains how to debug/manage the server (log meanings, etc.)?

Thanks.

[Guest]

Found the log file - still interested in the documentation.