SOS hangs during a get (and never succeeds)
Moderator: SourceGear
SOS hangs during a get (and never succeeds)
Hello, during a get of certain older versions of some files, the get just hangs and never completes. It only happens with certain versions of certain files (Rt. click, show history, select older version, and get). (It works fine using SS.)
The SOS log file says, "Exception getting file. An item with the name $/<ProjectPath> already exists."
We have SourceOffSite version 4.0.2 and I have reproduced the problem with client versions 4.0.2 and 3.5.2. SourceSafe on the server is version 6.0d (Build 31222 - which comes with Visual Studio 6.0 Service Pack 6). So the ssapi.dll is version 6.0.31222.0. I tried changing HKEY_CLASSES_ROOT\CLSID\{783CD4E4-9D54-11CF-B8EE-00608CC9A71F}\InprocServer32 "ThreadingModel" Key to "Both"and restarting the service but that did not fix the problem.
Any ideas?
Thank you,
mmcbride
The SOS log file says, "Exception getting file. An item with the name $/<ProjectPath> already exists."
We have SourceOffSite version 4.0.2 and I have reproduced the problem with client versions 4.0.2 and 3.5.2. SourceSafe on the server is version 6.0d (Build 31222 - which comes with Visual Studio 6.0 Service Pack 6). So the ssapi.dll is version 6.0.31222.0. I tried changing HKEY_CLASSES_ROOT\CLSID\{783CD4E4-9D54-11CF-B8EE-00608CC9A71F}\InprocServer32 "ThreadingModel" Key to "Both"and restarting the service but that did not fix the problem.
Any ideas?
Thank you,
mmcbride
The change of threading model to Both should only be used if you have VSS 6.0d with ssapi.dll version ending in 98.48.
I believe that Microsoft fixed the threading bug in later versions of 6.0d.
They were very helpful in working with SourceGear to fix the change in threading that affected SOS.
A hang in gets from history sounds like minor database corruption. Do you run Analyze regularly on you database?
http://support.sourcegear.com/viewtopic.php?t=50
I suggest this as a first step.
I believe that Microsoft fixed the threading bug in later versions of 6.0d.
They were very helpful in working with SourceGear to fix the change in threading that affected SOS.
A hang in gets from history sounds like minor database corruption. Do you run Analyze regularly on you database?
http://support.sourcegear.com/viewtopic.php?t=50
I suggest this as a first step.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Hello, thanks for the information. I will go ahead and change the registry key back and restart the service.
Regarding the SS analysis, we do analyze all of our SourceSafe databases weekly as suggested (2 passes with the first one running with the fix parameter). Unfortunately during the last analyze one of the files was open (apparently someone accidently left SS open), so I will try to run it again to see if there are any errors this week.
Thank you,
mmcbride
Regarding the SS analysis, we do analyze all of our SourceSafe databases weekly as suggested (2 passes with the first one running with the fix parameter). Unfortunately during the last analyze one of the files was open (apparently someone accidently left SS open), so I will try to run it again to see if there are any errors this week.
Thank you,
mmcbride
Hello,
I have fixed the registry key (and restarted the SOS service). I have run analyze with all of the recommended options on the SS database in question and all errors/information messages have been resolved. A SS analyze log file with level v3 logging shows no errors. However we are still seeing the same problematic SOS behavior: with certain files, we are still not able to get some older versions (it just hangs). Is there anything else we can do to resolve this?
Thank you,
mmcbride
I have fixed the registry key (and restarted the SOS service). I have run analyze with all of the recommended options on the SS database in question and all errors/information messages have been resolved. A SS analyze log file with level v3 logging shows no errors. However we are still seeing the same problematic SOS behavior: with certain files, we are still not able to get some older versions (it just hangs). Is there anything else we can do to resolve this?
Thank you,
mmcbride
I am not sure if this is the same issue or a different issue, but when I do a get latest on a project with subprojects things proceed very fast and then pause for a while and then proceed slowly, with additional long pauses. I enabled Verbose Logging; here is an excerpt:
7/21/2005 11:49:43 AM - 1: Ignore remote dates = False
7/21/2005 11:49:43 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus
7/21/2005 11:49:48 AM - 1: Time to execute: 0 minutes, 4 seconds, 718 milliseconds.
7/21/2005 11:49:48 AM - 1: Received message number 102.
7/21/2005 11:49:48 AM - 1: Ignore remote dates = False
7/21/2005 11:49:48 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin
7/21/2005 11:49:50 AM - 1: Time to execute: 0 minutes, 2 seconds, 203 milliseconds.
7/21/2005 11:49:50 AM - 1: Received message number 102.
7/21/2005 11:49:50 AM - 1: Ignore remote dates = False
7/21/2005 11:49:50 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin/Debug
7/21/2005 11:51:15 AM - 1: Time to execute: 1 minutes, 25 seconds, 295 milliseconds.
7/21/2005 11:51:15 AM - 1: Received message number 102.
7/21/2005 11:51:15 AM - 1: Ignore remote dates = False
7/21/2005 11:51:15 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin/Reference
7/21/2005 11:52:34 AM - 1: Time to execute: 1 minutes, 18 seconds, 311 milliseconds.
7/21/2005 11:52:34 AM - 1: Received message number 102.
7/21/2005 11:52:34 AM - 1: Ignore remote dates = False
7/21/2005 11:52:34 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin/Release
7/21/2005 11:54:25 AM - 1: Time to execute: 1 minutes, 51 seconds, 186 milliseconds.
7/21/2005 11:54:25 AM - 1: Received message number 102.
7/21/2005 11:54:25 AM - 1: Ignore remote dates = False
7/21/2005 11:54:25 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/CommonAppData
7/21/2005 11:54:29 AM - 1: Time to execute: 0 minutes, 4 seconds, 390 milliseconds.
7/21/2005 11:54:29 AM - 1: Received message number 102.
7/21/2005 11:54:29 AM - 1: Ignore remote dates = False
7/21/2005 11:54:29 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/CommonAppData/Registry Data
7/21/2005 11:54:33 AM - 1: Time to execute: 0 minutes, 3 seconds, 374 milliseconds.
7/21/2005 11:54:33 AM - 1: Received message number 102.
7/21/2005 11:54:33 AM - 1: Ignore remote dates = False
7/21/2005 11:54:33 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/CommonAppData/Registry Data/Individual Items
7/21/2005 11:54:46 AM - 1: Time to execute: 0 minutes, 13 seconds, 327 milliseconds.
7/21/2005 11:54:46 AM - 1: Received message number 102.
7/21/2005 11:54:46 AM - 1: Ignore remote dates = False
7/21/2005 11:54:46 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/Proteus.Setup
7/21/2005 11:54:52 AM - 1: Time to execute: 0 minutes, 5 seconds, 812 milliseconds.
As you can see some of the GetFileList take well over a minute, while others complete in a few seconds. While some of the projects which take longer do have more files (and larger files) it all seems unreasonably slow.
I am currently working with a client and server machine in the same building connected with a 100MHz LAN. The connection is using encryption; both machines are running Win XP SP2. I changed the ssapi.dll threading model to "Both" (and yes it's version # ends in 98.48. Nothing else is running on either client or server machine.
Both client and server are 4.1. I downloaded them both a few days ago. (I am a new user.)
7/21/2005 11:49:43 AM - 1: Ignore remote dates = False
7/21/2005 11:49:43 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus
7/21/2005 11:49:48 AM - 1: Time to execute: 0 minutes, 4 seconds, 718 milliseconds.
7/21/2005 11:49:48 AM - 1: Received message number 102.
7/21/2005 11:49:48 AM - 1: Ignore remote dates = False
7/21/2005 11:49:48 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin
7/21/2005 11:49:50 AM - 1: Time to execute: 0 minutes, 2 seconds, 203 milliseconds.
7/21/2005 11:49:50 AM - 1: Received message number 102.
7/21/2005 11:49:50 AM - 1: Ignore remote dates = False
7/21/2005 11:49:50 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin/Debug
7/21/2005 11:51:15 AM - 1: Time to execute: 1 minutes, 25 seconds, 295 milliseconds.
7/21/2005 11:51:15 AM - 1: Received message number 102.
7/21/2005 11:51:15 AM - 1: Ignore remote dates = False
7/21/2005 11:51:15 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin/Reference
7/21/2005 11:52:34 AM - 1: Time to execute: 1 minutes, 18 seconds, 311 milliseconds.
7/21/2005 11:52:34 AM - 1: Received message number 102.
7/21/2005 11:52:34 AM - 1: Ignore remote dates = False
7/21/2005 11:52:34 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/bin/Release
7/21/2005 11:54:25 AM - 1: Time to execute: 1 minutes, 51 seconds, 186 milliseconds.
7/21/2005 11:54:25 AM - 1: Received message number 102.
7/21/2005 11:54:25 AM - 1: Ignore remote dates = False
7/21/2005 11:54:25 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/CommonAppData
7/21/2005 11:54:29 AM - 1: Time to execute: 0 minutes, 4 seconds, 390 milliseconds.
7/21/2005 11:54:29 AM - 1: Received message number 102.
7/21/2005 11:54:29 AM - 1: Ignore remote dates = False
7/21/2005 11:54:29 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/CommonAppData/Registry Data
7/21/2005 11:54:33 AM - 1: Time to execute: 0 minutes, 3 seconds, 374 milliseconds.
7/21/2005 11:54:33 AM - 1: Received message number 102.
7/21/2005 11:54:33 AM - 1: Ignore remote dates = False
7/21/2005 11:54:33 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/CommonAppData/Registry Data/Individual Items
7/21/2005 11:54:46 AM - 1: Time to execute: 0 minutes, 13 seconds, 327 milliseconds.
7/21/2005 11:54:46 AM - 1: Received message number 102.
7/21/2005 11:54:46 AM - 1: Ignore remote dates = False
7/21/2005 11:54:46 AM - 1: GetFileList project: $/PEI Product Data/Software/Proteus/Proteus.Setup
7/21/2005 11:54:52 AM - 1: Time to execute: 0 minutes, 5 seconds, 812 milliseconds.
As you can see some of the GetFileList take well over a minute, while others complete in a few seconds. While some of the projects which take longer do have more files (and larger files) it all seems unreasonably slow.
I am currently working with a client and server machine in the same building connected with a 100MHz LAN. The connection is using encryption; both machines are running Win XP SP2. I changed the ssapi.dll threading model to "Both" (and yes it's version # ends in 98.48. Nothing else is running on either client or server machine.
Both client and server are 4.1. I downloaded them both a few days ago. (I am a new user.)
The time for the Get File List would vary depending on the size of the file list.
Are you by chance running real-time anti-virus scanning on the SOS Server machine? This can greatly impact on performance.
You might want to checkout this KB article for tips on improving SOS performance:
http://support.sourcegear.com/viewtopic.php?t=2575
Are you by chance running real-time anti-virus scanning on the SOS Server machine? This can greatly impact on performance.
You might want to checkout this KB article for tips on improving SOS performance:
http://support.sourcegear.com/viewtopic.php?t=2575
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Thank you. I was indeed running realtime antivirus; after disabling this performance is quite acceptable. However, I am seeing another issue when doing a Get Latest Version (recursive) on a large project tree:
After completing the get (i.e. the last folder appears with "Received file list" in the output window), the Client GUI does not seem to know that it is done. The hourglass cursor remains and most menus are disabled. I need to "Stop Current Operation" to get the client out of this state, at which point it attempts to reconnect to the server.
After completing the get (i.e. the last folder appears with "Received file list" in the output window), the Client GUI does not seem to know that it is done. The hourglass cursor remains and most menus are disabled. I need to "Stop Current Operation" to get the client out of this state, at which point it attempts to reconnect to the server.
I don't think so, Linda.lbauer wrote:Is there anything in the server log.txt file that corresponds to the hang?
Is it possible the connection was closed by a third party, such as a firewall?
It does not appear that the connection was closed; the GUI just sat there with the hourglass. I am attaching the log file; there were two operations in this log: a big tree diff and then a big tree get. At the end you can see where I manually shut down the server but this was after the hang.
- Attachments
-
- log.txt
- (161.75 KiB) Downloaded 849 times