Do we absolutely have proof that the original problem is caused for sure by session key collisions? The assertion here is that we're generating 10000 md5s and that NONE of those is unique and so the function is timing out.
This is preposterous. If this were actually the case, I could generate my own 10,000 md5s and log into each of those users sessions as an attacker. Sessions expire in 15 days. MD5 provides a reasonable distribution across the namespace. If you've generated 10k md5s and NONE of them is unique, you've got the md5 namespace pretty well covered (or you're using really bad random input data, which we are not), meaning your session key database has (conservatively) more than 10^20 petabytes of data. Right. The alternative explanation is that the cache backend is timing out. The 10k loop fix basically masked that issue by trying a bunch of times till it got a response. The fix for this issue is going to lie in improving behavior when the cache doesn't respond properly, not in fixing the key collision problem. Additionally, UUID4's are only very probably unique. You are proposing to move to a 103 bit random value (after excluding the fixed bits) instead of the existing 512 bit value. I predict that a patch which removes the 10k loop will make the problem worse, with or without UUIDs. Sorry to be blunt, but lets tackle the real problem here, rather than making things harder for ourselves. Best, -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
