Consultants
Moderator: SourceGear
Consultants
Does sourcegear offer any consulting service? We are having problems with Vault and we would like to have someone who can fix the problems quickly.
Every couple of days my users get a FailDBConn error with the following message.
System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
When I query the number of connections to the Vault database, it exceeded the maximum number of pooled connections. The maximum number of pooled connections were increased from 100 (default) to 200. Any more that 200 we get an OutOfMemoryException.
We do have a number of CruiseControl.NET projects (6 projects) that checks for modifications in Vault. These modification checks are done every five minutes. I think this is where most of the connections are consumed. What I do not understand is why these projects are consuming more than 200 connections to Vault.
The next problem that we are experiencing is after the FailDBConn error some users will get Unable to connect to http://<serverURL>. No server was found at the specified URL. All that we can do to resolve this issue is to reboot the server.
System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
When I query the number of connections to the Vault database, it exceeded the maximum number of pooled connections. The maximum number of pooled connections were increased from 100 (default) to 200. Any more that 200 we get an OutOfMemoryException.
We do have a number of CruiseControl.NET projects (6 projects) that checks for modifications in Vault. These modification checks are done every five minutes. I think this is where most of the connections are consumed. What I do not understand is why these projects are consuming more than 200 connections to Vault.
The next problem that we are experiencing is after the FailDBConn error some users will get Unable to connect to http://<serverURL>. No server was found at the specified URL. All that we can do to resolve this issue is to reboot the server.
I work with Ben. We have another problem with Vault. So all of our issues are consolidated in one place I'll post it here. If you want me to post a separate item, let me know and I will.
From time to time, more often for some people than others, when the Vault GUI program is started and it is attempting to connect with the Vault server, the Vault GUI progams pegs the cpu at 100% utilization for 10 mintues or more...sometimes up to 45 minutes before the program connects with server and display the Vault source tree. We have very fast XP computers. 45 minutes at 100% cpu utilization is a lot of processing for no apparent reason. Can you fix this as well? It happens multiple times per week for some programmers and less often for others. There seems to be no pattern to when or why. We are running 3.5.1 (4786) ususally on XP SP 1.
From time to time, more often for some people than others, when the Vault GUI program is started and it is attempting to connect with the Vault server, the Vault GUI progams pegs the cpu at 100% utilization for 10 mintues or more...sometimes up to 45 minutes before the program connects with server and display the Vault source tree. We have very fast XP computers. 45 minutes at 100% cpu utilization is a lot of processing for no apparent reason. Can you fix this as well? It happens multiple times per week for some programmers and less often for others. There seems to be no pattern to when or why. We are running 3.5.1 (4786) ususally on XP SP 1.
We've tracked down the cause of the 100% CPU usage failure, and have two workarounds.
1. Upgrade to the 4.1.1 client.
2. Uncheck the Tools->Options->Network Settings->Use database delta on repository cache miss checkbox. When 4.1.2 ships, you will need to recheck it. This option was accidentally boolean-flipped, and 4.1.2 will correct the mistake.
1. Upgrade to the 4.1.1 client.
2. Uncheck the Tools->Options->Network Settings->Use database delta on repository cache miss checkbox. When 4.1.2 ships, you will need to recheck it. This option was accidentally boolean-flipped, and 4.1.2 will correct the mistake.
Subscribe to the Fortress/Vault blog
Hi Jeremy,
Thank you for your response. I have a few questions.
If we upgrade to Vault client 4.1.1 are we also required to upgrade the server to the same version?
The Use database delta on repository cache miss checkbox settings is not present in our version of the Vault client (3.5.1). Perhaps you meant the workaround is applicable in version 4.1.1 of the client?
Thank you for your response. I have a few questions.
If we upgrade to Vault client 4.1.1 are we also required to upgrade the server to the same version?
The Use database delta on repository cache miss checkbox settings is not present in our version of the Vault client (3.5.1). Perhaps you meant the workaround is applicable in version 4.1.1 of the client?
Please check your server's version (I suspect that it's 3.5.2, which is where we introduced the bug and the option). If so, upgrade your client, and unselect that option.
Subscribe to the Fortress/Vault blog
Jeremy,
When I open my Vault client in the messages tab I find the following:
I would also like to know if your recommendation of upgrading the client would require us to upgrade the server as well. My experience with Vault is that there is a requirement that upgrading the one component, server or client, means that you need to upgrade the other component. Can you please clarify that? I like the idea of simply upgrading the client but not the idea of upgrading the server.
thank you,
BenV
When I open my Vault client in the messages tab I find the following:
This tells me that the version of our server is indeed 3.5.1. Unless there is is a bug in the Vault client where the returned version is wrong, I am more inclined to believe what I see in the Vault client.[5/2/2008 9:21:43 AM] Version Check: This Vault client is version 3.5.1.4786
[5/2/2008 9:21:43 AM] Version Check: Your Vault server is version 3.5.1.4786
[5/2/2008 9:21:44 AM] Version Check: The following information was retrieved from the SourceGear website. No information was sent to SourceGear. You can disable this part of the version check from the Options dialog.
[5/2/2008 9:21:44 AM] Version Check: The most recent Vault release is version 4.1.1.18060
I would also like to know if your recommendation of upgrading the client would require us to upgrade the server as well. My experience with Vault is that there is a requirement that upgrading the one component, server or client, means that you need to upgrade the other component. Can you please clarify that? I like the idea of simply upgrading the client but not the idea of upgrading the server.
thank you,
BenV
I believe you that you are on 3.5.1. I would like to verify a couple of assumptions really quickly.
1. You have lots of folders (hundreds of thousands).
2. You have lots of shared items (thousands).
Are those assumptions correct?
For now, I wouldn't recommend upgrading until we have a better idea what the root cause is.
1. You have lots of folders (hundreds of thousands).
2. You have lots of shared items (thousands).
Are those assumptions correct?
For now, I wouldn't recommend upgrading until we have a better idea what the root cause is.
Subscribe to the Fortress/Vault blog
We do have a lot of folders but I doubt that it is in the magnitude of hundreds of thousands. How can I find out quickly? Is there a Vault command or GUI interface that can tell me the folder count?
The same goes with shared items, I do not think that we have thousands of shared items. How can I find out the count of shared items?
The same goes with shared items, I do not think that we have thousands of shared items. How can I find out the count of shared items?
Ben,
I think that it's appropriate to take this offline, while I try to figure out what might be going on in this case. Please email support at sourcegear.com ATTN: jeremy with a link to this thread.
I think that it's appropriate to take this offline, while I try to figure out what might be going on in this case. Please email support at sourcegear.com ATTN: jeremy with a link to this thread.
Subscribe to the Fortress/Vault blog