soscmd fails during get

[rabbey]

SourceOffsite 4.2
SourceSafe 6, version of SSAPI.DLL, 6.0.31222.0

Hi

We're having problems performing a recursive get on a large project.
The get fails at different locations in the recursion and is not consistently failing at the same time.

On the client side, the GET fails with the following output

Code: Select all

Net error during attempt to read headers. (RH3). Error: 0 
Got file: c:\yyyyy\Customers\xxxxx\Source\Tasks\SupplierTimesheetExtract\TimesheetExtract.dbml
Could not open file \s3fg.uj.  Error Num=2
Error:  Server response = 203 File
Closed connection to server dev.yyyyy.com at port 8890.

In the server side log...

Code: Select all

$/yyyyy/Customers/xxxxx/Source/Tasks/SupplierTimesheetExtract/TimesheetExtract.dbml
8/23/2010 7:07:29 PM - 2: Getting version information: $/yyyyy/Customers/xxxxx/Source/Tasks/SupplierTimesheetExtract/TimesheetExtract.dbml.layout
8/23/2010 7:07:29 PM - 2: Getting version information: $/yyyyy/Customers/xxxxx/Source/Tasks/SupplierTimesheetExtract/TimesheetExtract.designer.cs
8/23/2010 7:07:29 PM - 2: Getting version information: $/yyyyy/Customers/xxxxx/Source/Tasks/SupplierTimesheetExtract/TimesheetExtractor.cs
Send failed: An established connection was aborted by the software in your host machine
8/23/2010 7:07:29 PM - 2: Exception: An established connection was aborted by the software in your host machine
8/23/2010 7:07:29 PM - 2: Error processing client request:    at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at ClassicService.MessageBody.Send(Socket socket, Crypto crypto, FileStream file)
   at ClassicService.Client.SendFile(ProtocolMessage messageIn, ProtocolMessage messageOut, IVSSItem file, String strParentProject, Boolean bCompress, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.SendFile(ProtocolMessage messageIn, IVSSItem file, String strParentProject, String strResponseTo, Boolean bCompress, Boolean bLockFile, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.SendFiles(ProtocolMessage messageIn, IVSSItem project, String strResponseTo, Boolean bRecursive, Boolean bCompress, Boolean bLockFiles, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.SendFiles(ProtocolMessage messageIn, IVSSItem project, String strResponseTo, Boolean bRecursive, Boolean bCompress, Boolean bLockFiles, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.SendFiles(ProtocolMessage messageIn, IVSSItem project, String strResponseTo, Boolean bRecursive, Boolean bCompress, Boolean bLockFiles, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.SendFiles(ProtocolMessage messageIn, IVSSItem project, String strResponseTo, Boolean bRecursive, Boolean bCompress, Boolean bLockFiles, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.SendFiles(ProtocolMessage messageIn, String strProject, String strResponseTo, Boolean bRecursive, Boolean bCompress, Boolean bLockFiles, Boolean bUnixEOL, Boolean bMacEOL, Boolean bIsDeleted)
   at ClassicService.Client.GetProject(ProtocolMessage messageIn, ProtocolMessage messageOut, Boolean bLockFiles)
   at ClassicService.Client.ProcessMessage(ProtocolMessage messageIn, ProtocolMessage messageOut)
   at ClassicService.Client.GetMessage()
8/23/2010 7:07:29 PM - 2: User i.g disconnected from rrcs-11-22-33-44.west.biz.rr.com.
8/23/2010 7:07:29 PM - 2: Error removing user temp folder 'C:\Program Files\SourceOffSite Server\temp\i.g634181871343750000'.
8/23/2010 7:07:29 PM - 	The process cannot access the file 'TimesheetExtractor.cs.z' because it is being used by another process.

I've seen a couple of threads related to this. So...
I've tried with and without -nocompress option. Makes no difference
I've set the Apartment threading model on SSAPI.DLL to Both (and restarted SOS server). Makes no difference

Thanks in advance

[lbauer]

There are a number of things that can cause a problem with a large get -- network, database, automation component, etc. We'll try to narrow it down.

Is this a new problem? Were you able to do these Gets previously with the Command Line Client?

Can you do the Get on the SOS Server machine itself, using "localhost" for the SOS Server name? Doing this should bypass any network issues.

It looks like you are using Encyption. As a test, if you use the non-secure post, does the Get succeed?

[rabbey]

Thanks for your reply

I think this problem has been occurring for a while and just hadn't noticed. Except that the problem became much worse recently. That recent change is likely related to an upgrade of firmware on a Sonicwall firewall.

When I looked back over the log.txt file, I'd noticed similar errors have been occuring.

We needed to get this working ASAP, so I installed SOS Server 4.2 on the remote server that had the get problem and moved the source database onto the remote server.

This has improved the problem to the extent that our builds are successful, rather than failing all the time.

However, when performing a couple of test gets prior to restarting our build process, I did manage to reproduce the file error and the get failed. But it's no longer almost guaranteed to fail like it was across the WAN.

So the get command uses the external server name, which is effectively pointing to itself, but I will make some tests referring to the localhost as the server and post the results if you think it will be different than referring to it's external name

[lbauer]

Yes, "localhost" is still different than the server name, since that name still needs to resolve on the network. You could also try another test using the IP address.

Also, try using the unsecure port. This to enable this setting, look in the SOS Server manager in the General Settings tab.

For remote clients having a problem with the Get, have they adjust the MTUs on their network cards. This setting may or may not be applicable if you're doing the Get on the server machine, using Localhost.