Vault API Client has intermittent cache corruption.

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Vault API Client has intermittent cache corruption.

Post by dking513 » Fri Nov 18, 2005 9:20 am

Hello,
I have a custom application that uses the Vault API. I am finding that periodically this application loses the ability to get files, or reports incorrect information during checkin (local version needs merge when it doesn't, or local copy hasn't been modified when it has). In any of these cases I have found that closing the custom app, deleting the client side cache folder, and restarting the client fixes the problem. I would like to get to the bottom of what is causing this, and figure out how I can prevent it.

I can't find any pattern to when it happens. The one thought I have is that this cusom app can stay open and connected for very long periods of time. I don't know how the cache works, when it is held in memory or stored to disk, but perhaps I need to save periodically with a TreeCache.Save() ? Also, I am not sure the difference between a .Refresh and a .DoLocalRefresh. I call .Refresh often, but not .DoLocalRefresh.

Any insight would be much appreciated.
Thank you.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Some more information

Post by dking513 » Fri Nov 18, 2005 1:54 pm

It looks like this problem occurs when more than one instance of the application is running on the machine at a time. I assume they both write to the same disk cache, and my current hypothesis is that one instance makes some changes to disk that confuses the other instance. Does this sound like a feasible cause? What safeguards can I take when using the API to avoid this? Calling .Save after a .Refresh?

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Fri Nov 18, 2005 2:49 pm

more than one instance of the application is running on the machine at a time
Cache files can get out of sync when two users use the same working folder. Are your instances running under different accounts?

It's possible that even two instances of the same account can cause the cache to get out of sync.
Linda Bauer
SourceGear
Technical Support Manager

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Fri Nov 18, 2005 2:52 pm

Both instances are using the same account. It is equivalent to opening two instances of the Vault Client GUI on one machine (both logged in as the same user). I believe I have done this before with the client GUI with no issues, so the Client GUI must be doing something to keep the cache in order that my custom API application is not.

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Mon Nov 21, 2005 2:49 pm

Two clients should be able to run at the same time - we support having the GUI client, the IDE client, and the CLC all at the same time.

Yes, doing a periodic TreeCache.Save and a DoLocalRefresh would probably help. Refresh() is a server side op, and doesn't apply, but DoLocalRefresh attempts to update the status of any local files.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Mon Nov 21, 2005 2:57 pm

Thank you Dan,
Could you please explain the difference between .Refresh and .DoLocalRefresh? I am worried that perhaps I misunderstand when it is appropriate to call each one.

You say that .Refresh is a server side op... I am under the impression that it fetches new tree folder/file information from the server (like files added since last refresh, or checkout since last refresh, etc) and updates the client cache. I am not sure what .DoLocalRefresh would do differently. My custom application is quite sensitive to performance, so even if there was a subtle difference between the two Refreshes I would be interested in understanding the difference.

Thank you,
Dave

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Mon Nov 21, 2005 3:38 pm

Sorry, should have been more clear. Refresh() brings the client up to date with the server, so it is getting server info, but yes, it updates the local cache after it is done so the local cache contains the correct server info.

LocalRefresh() updates the change set of known changes so that the status of those files (on the local machine) are up to date. So, if some other program modified a file, the change gets picked up in LocalRefresh().

I would add both of these calls to your app prior to an operation, and see if it addresses the file status issues. It may slow down the app, but we would at least know that the problem is related to that somehow.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Mon Nov 21, 2005 3:44 pm

Thanks - that was a good clarification.
Just one more question then,
What does TreeCache.Save do?
When do you feel it's appropriate to call this?

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Tue Nov 22, 2005 2:55 pm

TreeCache.Save() will explicitly save all the client cache files. Some of the cache files are not saved immediately when they change because there is so much data (like the repository file).

I would suggest sprinkling these around your custom app as well, and seeing whether that helps.

Locked