Vault server status different than client for checkouts

joel · Post by **joel** » Thu Feb 10, 2005 5:13 pm

I've had several users mention that checked out files are reverting to not checked out in the client status, yet the server still acts as if their files are checked out.

I've seen the same issue on my box. In my case, the checkout had failed and then the server still thought I had the file checked out. To fix, I had to undo the checkout through the Admin Tool. Another user fixed it by removing all local cache files except the repository one, therebly forcing the server to update the status.

We hadn't seen this issue til upgrading to Vault 3.0. Any ideas?

Thanks,
Joel

Post by **jclausius** » Fri Feb 11, 2005 6:59 am

Joel:

When a checkout occurs, these happens in a non-atomic manner in the server. First the file is locked, and then the client retrieves the file.

Is it possible, the checkout lock is acquired, and then retrieval is failing for some reason? That would explain the situation you described.

Do you have more information here?

Do you use the GUI client or the IDE client?

In either case, when one of the locks appears to have been lifted, if you check the other Vault client, is it still checked out?

Any other information that you think might shed some light on the situation.

Post by **jclausius** » Fri Feb 11, 2005 7:26 am

A couple of follow-up questions:

- This may be a bit time-consuming, but can you verify the version for each Vault client ( or at least of the people who have reported the problem ).

- What version of Vault 3 is the server?

- For the people who were removing their client side cache files, do they remember their last action before seeing the problem?

joel · Post by **joel** » Fri Feb 11, 2005 2:54 pm

It is definitely possible that the retrieval is failing and that causes the cache to get out of sync.

We use both GUI and IDE clients, but these problems have all been reported on the GUI.

Not sure what their last actions were prior to seeing the problem, but I will ask upon any future instances.

All clients are 3.02, as is the server.

Since we experience significant lag time and frequent failures, this is a big problem. We have roughly 80 developers, with upwards of 30+ hitting the server at any one time and we often have IIS using 1+ gigs of memory. Once Vault hits that wall, it starts throwing OutOfMemory exceptions, forcing us to do at least one IIS reset per day just to clear the memory so we can continue. This means that cache sync problems could become very common, due to the resets. We had hoped the performance problems would be fixed in 3.0, but we still have some of those in addition to this caching problem, which didn't show up til the upgrade.

joel · Post by **joel** » Fri Feb 11, 2005 4:05 pm

One other question: why is the checkout not a transaction, like all other actions in Vault? I would expect the entire checkout to succeed or fail, rather than leaving it in an unknown state.

Post by **jclausius** » Sat Feb 12, 2005 9:26 pm

joel wrote:Once Vault hits that wall, it starts throwing OutOfMemory exceptions, forcing us to do at least one IIS reset per day just to clear the memory so we can continue. This means that cache sync problems could become very common, due to the resets.

To address this, let's try scaling back the caching strategy of the server. Can you set your TreeManagersize to 25, and then reset the server.

After the change, keep an eye on your memory consumption. Post back if this did not address the problem.

--------------------------------------------
[EDIT] - scratch this. See my post below.

Post by **jclausius** » Sat Feb 12, 2005 9:32 pm

joel wrote:One other question: why is the checkout not a transaction, like all other actions in Vault? I would expect the entire checkout to succeed or fail, rather than leaving it in an unknown state.

A good question.

Locking files operate at a per lock request. In some instances someone may attempt to lock a group of files, where one may be exclusively locked. The server tries to be accomodating as possible, so not to upset the user, and will grant locks to the other files.

Now, if a get fails, and the client assumes you are still intending to modify the file. So in this case, you wouldn't want to release the lock. Since you are intending to modify the file, the client assumes the user will rectify the condition which caused failure in get ( ie. merge problem ) and just reattempt the get while maintaining the lock.

Post by **jclausius** » Sat Feb 12, 2005 9:45 pm

Joel:

I didn't realize it was "the Joel". Sorry about that. You can disregard my treemanagersize stuff, as I believe we already addressed that.

Since we already have a pre-established relationship, I'm going to contact you offline.