On 8/20/14 9:13 AM, Ben Reser wrote:
> I think part of the problem here has been we (as in WANdisco folks) have
> discussed the idea of an instance ID for repositories in the past to solve the
> range of replacing the repository without clearing the cache issues. But this
> change is being added for a very different reason.
>
> Evgeny has implemented the instance ID for the purpose of solving the problem
> of two different repositories not being able to be locked if they happen to
> have the same UUID. This happens because we use a mutex to handle locking
> between threads and that mutex can't distinguish between different repositories
> with identical UUIDs.
>
> Currently the code on trunk adds the instance ID to the cache keys. I'm not
> sure we should be doing that (though both brane and stefan2 requested that be
> done). As per the discussion today at the SHF hackathon the instance ID can't
> resolve the failure to clear the cache issues. The best it can do is narrow
> the window for these issues to exist. That would seem like a good thing but I
> think it creates a huge false sense of security. We will ultimately have
> someone that comes along with a corrupted repository, we're going to say you
> replaced the repo while the server was running and the user is going to say
> "But I've been doing this for years without any problem."
>
> Without the instance ID in the cache keys users are unlikely to actually
> corrupt their repository (just like they would be with them, it's a pretty hard
> race to hit). But they are likely to get errors related to the cache being
> stale. This gives them a giant hint that what they're doing is wrong and gives
> us an opportunity to educate them.
Evgeny do you have any thoughts on this? I think it's probably best to remove
the instance id from the cache keys. I believe brane and stefan2 were
convinced of this at the hackathon.
Received on 2014-09-02 19:28:38 CEST