Error 400 on CheckIn
Moderator: SourceGear
Error 400 on CheckIn
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
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
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?
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
SourceGear LLC
VSS Fix and Full Command
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!
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!
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
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
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.
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
SourceGear LLC
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.