https://issues.apache.org/bugzilla/show_bug.cgi?id=53022
--- Comment #7 from Leonardo Uribe <lu4...@apache.org> 2012-04-03 02:20:59 UTC --- After evaluating the probabilities, it seems to be the size of the key is critical. Since by default sessionIdLength is 16, there are 2^128 = 3.4e38 possible combinations. So, the possible number of sessions in a single tomcat instance and the ammount of request a tomcat instance is capable to handle in a reasonable frame of time is much more less. The duplicate check is useless, because it will not affect significantly the probability, but a single lookup over a ConcurrentHashMap is cheap enough to let it (because the duplicate should happen in a even shorter frame of time). Anyway, a simple check taking the value returned by put() operation, could easily detect the occurrence, and it is not necessary to do anything more than restore the old session in the map, and throw an exception for the new one. It will be enough to prevent the duplicate session effect at 100% and they are just some few lines of code. Other different history will happen if the user reduce sessionIdLength, but there is nothing to do in that case, maybe a check for a minimal sessionIdLength is reasonable, but it is questionable because usually you want that key be large enough to make computationally infeasible to find it by brute force. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
