TFS checks for change set timeout containing large binaries

Question

I am migrating TFS integration from tfs.visualstudio to the local 2012 server. I have a problem with a specific change set that contains several binary files larger than 1 MB, some of which are 15-16 MB. [I work remotely (WAN) with local TFS]

From the TFSI logs, I can see: Microsoft.TeamFoundation.VersionControl.Client.VersionControlException: C:\TfsIPData\42\******\Foo.msi: The request was aborted: The request was canceled. ---> System.Net.WebException: The request was aborted: The request was canceled. ---> System.IO.IOException: Cannot close stream until all bytes are written. Microsoft.TeamFoundation.VersionControl.Client.VersionControlException: C:\TfsIPData\42\******\Foo.msi: The request was aborted: The request was canceled. ---> System.Net.WebException: The request was aborted: The request was canceled. ---> System.IO.IOException: Cannot close stream until all bytes are written.

While doing some things on Google, I was faced with others encountering similar issues, not necessarily related to TFS Integration. I am sure that the same problem would occur if I just checked the set of changes, as usual, that met the same criteria. As I understand it, when downloading files (checking), the default block size is 16 MB, and the timeout is 5 minutes.

My internet download speed is only 1 Mbps on this site. (Although I think that the problem will be mitigated with sufficient download bandwidth, this will not solve the problem).

Using TCPView, I watched the connection to the TFS server from my client at boot time. What I see is 9 concurrent connections. Thus, my bandwidth is distributed between 9 file downloads. Of course, after about 5 minutes, the connections end before the number of download bytes can end.

My question is how to configure my TFS client to use fewer concurrent connections and / or smaller block sizes and / or increase timeouts? Can this be done globally anywhere to cover VS, TF.EXE and TFS Integration?

Answer 1

After spending some time with IL DASM picking at Microsoft.TeamFoundation.VersionControl.Client.dll FileUploader, I found the VersionControl.UploadChunkSize line in the constructor. It looks like it is used to override the default block size (DefaultUploadChunkSize = 0x01000000).

So, I added this to TfsMigrationShell.exe.config

 <appSettings> <add key="VersionControl.UploadChunkSize" value="2097152" /> </appSettings> 

and redirected VC migration again - this time it passed a problem check!

Basically, the TFS DLL client will try to download multiple files at the same time (9 in my case). Your download bandwidth will be split between files, and if any individual file transfer fails to complete 16 MB in 5 minutes, the operation will fail. Thus, you can see that with moderate bandwidth utilization, variables containing multiple binaries can time out. The only thing you can control is the byte of each 5 minute timeout. The default value is 16 MB, but you can reduce it. I reduced my production to 2 MB.

I assume that this can be done for devenv.exe.config to solve the same problem when doing developer code verification. Hope this information helps someone else and save some time.