Possible disc cache key conflict - Wrong image returned about glide HOT 4 CLOSED

The two functions at fault are:

https://github.com/bumptech/glide/blob/master/library/src/com/bumptech/glide/resize/ImageManager.java#L627
https://github.com/bumptech/glide/blob/master/library/src/com/bumptech/glide/util/Util.java

The underlying reason for this bit of ugliness is that the disk cache implementation throws an exception if keys don't match the regex [a-z0-9_-]{1,64}. At some point someone has to be responsible for normalizing keys that don't match.

The Util.hash function should be improved and should probably return a 64 digit number rather than a 10 digit 32 bit integer which will help reduce collisions. Since the disk cache doesn't handle key collisions, we can't ever entirely solve this problem, but we should be able to make it very rare.

I just started a new job so I'm short on time, but if this seems reasonable to you I'll try and get something better up this week.

from glide.

Seems ok, I saw a discussion in SO about functions to calculate a better hash in a disc cache to avoid collisions but also improve the speed of the calculation. I think UUID was the winner but I'm not sure.

from glide.

Here it is:

• http://stackoverflow.com/a/16897129
• http://stackoverflow.com/questions/772802/storing-uuid-as-base64-string/18057117#18057117

Another possibility would be:

• get the hashcode, convert it to 64, do a XOR|OR with the first/last X chars of the URL and convert to HEX
• Base64 of the URL

from glide.

I saw your comment as I was finishing up something using sha-256. I'll take a look at the uuid questions. If it's a trade off between speed (uuid) and correctness (sha-256, 64 characters vs 32 for uuid), I'd probably rather use aggressive caching and be a bit slower the first time around.

I took a look at trace view and for uncached keys using sha-256, it took about 70ms to generate the keys for 26 or so different images. At 2-3ms per image, it's not a substantial performance hit.

from glide.