DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-09 01:03 ------- (In reply to comment #56) > Looks like the problem will hard to reproduce as it requires a situation > where a > write to the hashmap causes a table resize/reindex to occur while another > thread > is reading from the hashmap. > > I would have thought it would return a null when it couldn't find the value. > But there is no guarantee on what happens. > It should return a null when you simply look at it the code. I can't reproduce the infinite loop myself, but Leon says he can reproduce the problem, and if it's so then it's a problem (Murphy's Law), and I definitely see that it is possible to add an attribute then later while a write is occuring to ... for instance ... be logged in to some application which is relying on session variables and the system think you are not then get kicked out because of concurrency issues in with the HashMap not being synchronized because the system thinks a session attribute/variable isn't set when it is. The original set could have occurred hours before then just when the read is occuring a write takes place which resizes the HashMap, and then an issue arises which makes web apps unpredictable in Tomcat....you can predict it by knowing the default size of the Map and not using more session variables than the Map threshold to size I suppose, but give me a break. I can't say for certain, myself, whether the infinite loop will occur just syncing the writes or not, but the way the get method works with the index being calculated for the hash bucket (array index) you can certainly say it's unpredictable and it can definitely cause goofy errors. So an INVALID resolution seems irresponsible for this issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
