Vault API Client has intermittent cache corruption.
Moderator: SourceGear
Vault API Client has intermittent cache corruption.
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.
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.
Some more information
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?
Cache files can get out of sync when two users use the same working folder. Are your instances running under different accounts?more than one instance of the application is running on the machine at a time
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
SourceGear
Technical Support Manager
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.
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.
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.
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
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
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.
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.