Problem checking out files using vault client

gweinhold · Post by **gweinhold** » Fri Dec 10, 2004 1:56 pm

Hello,

I'm using Visual Build Pro to do a "getlatest" and then "checkout" of my solution. I am getting an error about 5 minutes into the checkout:

Code: Select all

<vault>
<error>
The Vault server could not be contacted to perform the operation.  Your network connection to the server may have been interrupted.  Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client.
</error>
<exception>
System.Exception: The Vault server could not be contacted to perform the operation.  Your network connection to the server may have been interrupted.  Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client.
   at VaultClientNetLib.VaultConnection.GetCheckOutListChanges(Int32 nRepID, Int64& revision, DateTime& lastUpdate, Boolean& completeListReturned, VaultCheckOutItem[]& newItems, VaultCheckOutRelease[]& releaseItems)
   at VaultClientOperationsLib.ClientInstance.RefreshCheckOutList(Boolean isRetry)
   at VaultClientOperationsLib.ClientInstance.CheckOut(VaultClientFile[] files, Byte checkOutType, String comment)
   at VaultCmdLineClient.VaultCmdLineClient.ProcessCommandCheckout(ArrayList strItemArray)
   at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
   at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
</exception>
<result success="no" />
</vault>

Process completed with exit code -1

The GetLatest worked just fine with the same server/connection settings. I also noticed SQL server taking up a large amount of the CPU after receiving the error. In looking at SQL Enterprise Manager I see 4 spids for the vault service account, all of them have as their "last TSQL command batch" of "dbo.spgetlockedfilechangeswithsecurity;1". Command type was "INSERT" as well. As I'm writing this, SQL has calmed down now though. (FYI, this system is a win2k3 box w/ sql2k standard, dual 1.3ghz cpu, 2gb ram, very low usage (~3 devs using vault max concurrently).

Any ideas?

gweinhold · Post by **gweinhold** » Fri Dec 10, 2004 2:04 pm

Actually, I spoke too soon. SQL server has hung now. I will restart SQL to see if I can try again.

Looks like SQL is hung after restart of services. I will restart the box to see if that helps SQL recover.

Post by **jclausius** » Fri Dec 10, 2004 2:04 pm

Check the server's log. Do you see anything related to a SQL timeout?

gweinhold · Post by **gweinhold** » Fri Dec 10, 2004 2:17 pm

I just changed the logging in the admin from Quiet to Debug level logging. I have re-started the Checkout from the client to see if I can trap it again. SQL is currently maxing out the CPU again while it is running.

I see the 4 spids again taking up the cpu with last command of "dbo.spgetlockedfilechangeswithsecurity;1".

By the way, I am running vault 3.0. Sorry for not saying that earlier.

gweinhold · Post by **gweinhold** » Fri Dec 10, 2004 2:42 pm

After rebooting, it appears that the initial login from the vault gui on my workstation is initially slow. However, the solution and sub-projects are quite large. I do see that all of my files (that i've poked through so far) are checked out by my build account, a good thing. Is it possible that with a solution that is very large that the overhead for checkout and getting status is too much, causing timeouts?

btw, nothing in systemroot\temp\sgvault for today yet.

Post by **jclausius** » Fri Dec 10, 2004 3:41 pm

Could be a timeout in the Web request. Normally, you should check out any files you intend to modify. How many files did you checkout? Was the checkout in VS.Net or the Vault GUI client?

gweinhold · Post by **gweinhold** » Fri Dec 10, 2004 4:03 pm

Checkout was done with Vault Client via support with Visual Build Pro. I agree that we should be checking out only the files necessary, but I was really only in the position of modifying our existing build script. I was simply mimicking our source control actions with those of Vss.

I believe the build process is checking the files out to increment the build numbers and then label the files. I'm not sure if it is intending on labeling all of the files or not though. This is a project that I've recently inherited.

The number of files being checked out would be ~1,000.

Post by **jclausius** » Fri Dec 10, 2004 4:58 pm

While I wouldn't recommend checking out 1000 files, that number is not too big. A checkout list can be somewhat expensive to calculate when it is large with folder security enabled, but we've made optimizations here for large repositories w/ a large number of security items in place.

I don't believe the timeout is happening by the Vault client, as a normal Vault client, the web request times out after 2 hours.

Let's examine the server side of things.

Is there something possibly interferring w/ Vault's web.config setting for a request timeout ( Vault's web.config attribte for executionTimeout in the httpRuntime element ) - Something like another web.config in your inetpub\wwwroot directory?

Or perhaps the setting in the Virtual Directory for connection timeout is causing the problem? Vault server's web.config is supposed to override this value, but perhaps something is getting in the way here?

gweinhold · Post by **gweinhold** » Fri Dec 10, 2004 5:08 pm

Here is the line from my web.config in C:\Inetpub\wwwroot\VaultService. This is the only project I currently have underneath C:\inetput\wwwroot\ . No web.config in C:\inetpub\wwwroot.

Code: Select all

    <httpRuntime executionTimeout="86400" maxRequestLength="102400" useFullyQualifiedRedirectUrl="false" minFreeThreads="8" minLocalRequestFreeThreads="4" appRequestQueueLimit="100" />

I don't see anything out of the ordinary for the VaultService virtual directory, but I am somewhat new to Windows 2003 server. I don't know if any of the settings for the Application Pool are off-base though.

Post by **jclausius** » Fri Dec 10, 2004 6:36 pm

If you look at the properties of the Vault Service directory, there is a connection timeout. By default, it is 120 seconds.

Again, Vault's web.config is supposed to override this value. How long did it take for the timeout to occur? Was it about the same as this value? I don't think it will matter, but you could try increasing this value, to see if it has any effect.

gweinhold · Post by **gweinhold** » Mon Dec 13, 2004 10:39 pm

I suppose the checkout took about 120 seconds, but can't be sure without taking a closer look when executing. In looking closer at our build process however, I see we're just trying to checkout the proj files and AssemblyInfo files to auto-increment the version information.

I see there now is a -wildcard option in the client, does it support multiple wildcards or just a single entry? I think I can work around this by creating additional steps for each wildcard type I'd like to checkout, but was wondering if I was overlooking something.

Post by **jclausius** » Tue Dec 14, 2004 7:11 am

I believe so. Just supply "*.csproj assemblyinfo.c? *.txt ..." ( without the quotes ) on the end of your GETWILDCARD command.

suceava · Post by **suceava** » Fri Feb 04, 2005 3:41 pm

Can you use the -wildcard option with the checkout command or only with the getwildcard? Because the option shows up when doing help for checkout, though it gives me errors saying the file 'x.*' does not exist.

Post by **jclausius** » Fri Feb 04, 2005 4:05 pm

Yes. But you must make sure you specify a starting point for the checkout. I believe the following should work:

vault.exe -server vaultserver.dom.com -user jeffc -password somepwd -repository repTest CHECKOUT $/dirA/dirB -WILDCARD *.bin

SourceGear Support

Problem checking out files using vault client

Problem checking out files using vault client

-wildcard with Checkout