Error 400 on CheckIn

If you are having a problem using SourceOffSite, post a message here.

Moderator: SourceGear

Post Reply
KiphsMike
Posts: 5
Joined: Fri Jul 09, 2004 11:42 am

Error 400 on CheckIn

Post by KiphsMike » Wed Jul 28, 2004 3:06 pm

Client and Server are both SOS 4.0.2.Standard
Server Information (according to log file)
Operating System: Microsoft Windows 2000 Server
Service Pack: 4.0
OS Version: 5.0.2195
Locale: Ox0409
OSLanguage: 1033
Total Physical Memory: 127.55 MB
Client Information
WinXP Pro SP1

When I check in a file, the file gets checked in correctly, but if I'm using the GUI client it doesn't show as checked in until I refresh the directory (which takes a really long time). Or if I'm using the command line client I get :

Error: Server response = 400 OperationFailed

The server log says:
7/28/2004 3:49:28 PM - 3: Open the database.
7/28/2004 3:49:28 PM - 3: 'user' connected to database \\server\share\vss\srcsafe.ini
7/28/2004 3:49:28 PM - 3: Received message number 110.
7/28/2004 3:49:28 PM - 3: Ignore remote dates = False
7/28/2004 3:49:31 PM - 3: File "D:\SourceServer\temp\user632266265686541808\b-prledg.gc" not found (8004d83e)
7/28/2004 3:49:31 PM - 3: Received message number 199.
7/28/2004 3:49:31 PM - 3: User user disconnected from MACHINE.

(I changed the user name, server\share, and machine name in this log segment ).


I don't know if this is a seperat issue, or if this will help, but when i do a GetProject using soscmd, it always crashes (soscmd.exe has encountered a problem and needs to close) and the log file shows:
7/28/2004 3:58:07 PM - 4: GetFileList project: $/PROJECT/SUBPROJECT
7/28/2004 3:58:31 PM - 4: Time to execute: 0 minutes, 24 seconds, 4 milliseconds.
...
7/28/2004 3:58:45 PM - 4: Received message number 112.
7/28/2004 3:58:45 PM - 4: Version information obtained: D-CHGDAT.W
7/28/2004 3:59:07 PM - 4: Exception: An existing connection was forcibly closed by the remote host
7/28/2004 3:59:08 PM - 4: Error processing client request: at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 size, SocketFlags socketFlags)
at ClassicService.ProtocolMessage.ParseStream(Socket socket, Crypto crypto)
at ClassicService.Client.GetMessage()
7/28/2004 3:59:08 PM - 4: User user disconnected from MACHINE.

The crash happens on the same file. We've run Analyze on our VSS 6.0 database. I've deleted the project from my client machine. I've uninstalled and reinstalled SOS on my client. I've run diskcheck and defrag on my client. I've even changed ISPs. But the chrash just happens on a different file (same project). The GetProject works through the GUI though if it can stay connected long enough.

Send failed: An existing connection was forcibly closed by the remote host

is a pretty common entry in the server log file.

Any ideas?

Thanks,
Mike Fields

corey
Posts: 250
Joined: Tue Dec 30, 2003 10:13 am

Post by corey » Thu Jul 29, 2004 2:46 pm

For the Check In problem, please see the following KB article and see if it helps:

http://support.sourcegear.com/viewtopic.php?p=5446#5446

For the CLC Get problem, can you give us the exact command you are issuing from the command line?
Corey Steffen
SourceGear LLC

KiphsMike
Posts: 5
Joined: Fri Jul 09, 2004 11:42 am

VSS Fix and Full Command

Post by KiphsMike » Thu Jul 29, 2004 3:09 pm

Changing that option in VSS fixed my check in problem. Thanks. I searched the KBase, but I was searching on Error 400. I guess that's why I missed that solution.

Anyway, here's the command i'm using for the checkout
C:\Develop\SourceOffSite\soscmd.exe -command GetProject -server serverip:port -name user -password password -database \\servername\share\vss\srcsafe.ini -project $\4.4\ENCOUNT -workdir i:\source\dvkiphs\ENCOUNT -recursive -verbose

Thanks!

corey
Posts: 250
Joined: Tue Dec 30, 2003 10:13 am

Post by corey » Fri Jul 30, 2004 9:36 am

It appears that your network may be timing out your connection which is causing the problem you are having with the SOS command line client. What type of a firewall or proxy are you passing through to get to the server?
Corey Steffen
SourceGear LLC

KiphsMike
Posts: 5
Joined: Fri Jul 09, 2004 11:42 am

Post by KiphsMike » Fri Jul 30, 2004 9:59 am

I'm using a VPN to get to a Watchguard SOHO router on my companies end. I'm also passing through whatever my ISP is using, but the problem was the same with two different ISPs.

The timeout problem is believable since I have lots of problems with the GUI client staying connected long enough to refresh a large project. But why would a timeout cause a GPF with the command client. Wouldn't it just drop? I only get the GPF on one particular project.

I keep a Remote Desktop Connection open to my companies server (same box that SOS server is on) and I don't have any problems with connectivity to that.

What kind of information do I need to get for you?

Thanks

KiphsMike
Posts: 5
Joined: Fri Jul 09, 2004 11:42 am

Post by KiphsMike » Fri Jul 30, 2004 10:00 am

I forgot to add. No proxies.

corey
Posts: 250
Joined: Tue Dec 30, 2003 10:13 am

Post by corey » Fri Jul 30, 2004 10:10 am

The GPF in the CLC could just be a bug in the CLC with not being able to handle a closed socket gracefully within that method.

Could the reason why its always happening in the same project be because that's the location you reach each time the timeout occurs? We noticed in the log file that the connection seemed to drop exactly one minute (I think) after the operation began.

Why SOS would have problems when other apps do not could be due to inactivity on the socket. Some operations in SOS require a lot of processing by the server during which time there is no activity on the socket and that's when the socket is closed by some networks.
Corey Steffen
SourceGear LLC

KiphsMike
Posts: 5
Joined: Fri Jul 09, 2004 11:42 am

Post by KiphsMike » Fri Jul 30, 2004 10:51 am

So what do I need to tell my guys to set on their router/firewall? Increase (or eliminate) the timeout on the port we're using?

corey
Posts: 250
Joined: Tue Dec 30, 2003 10:13 am

Post by corey » Fri Jul 30, 2004 11:37 am

Yes. If they'd be willing to do that at least as a test (completely eliminate any timeout on that port), we'd know for sure if its the cause of the problem.
Corey Steffen
SourceGear LLC

Guest

Post by Guest » Thu Aug 05, 2004 8:29 am

My guys said they didn't have any settings on the router/firewall for port timeouts so that looks like that is out of our hands. I'm still having problems staying connected long enough to refresh a large project (couple hundred files) through the GUI client, but I'm not having any problems (no more GPFs) with the CLC. I defraged my source drive, and they ran Analyze on the VSS database. I still had a GPF or two after those things, but this week I haven't had the GPF problems.

Post Reply