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-08 18:47 ------- (In reply to comment #38) > All the entry objects will be mutated. While it may be inconsistent and might > loop for an instant (although I am not convinced this could really be the > case; > I think the trouble without any sync could only occur if there was more than > one > concurrent unsynced write, and in particular, two "remove"), the pointer value > will be corrected and the loop should exit. That's my interpretation looking > at > the code. I think I'll write a small program to test this. Ok, I wrote a program which can reproduce the bug even with tomcat 5.5 conditions, with synchronized put/remove and unsynchronized get. I must correct myself, since it doesn't produce an infinite loop, but just a very LONG LASTING FINITE loop, and I am talking about hours or days of execution. I do following: Having X writer and X reader threads, which modify (set or remove by 50% chance) and read 10 mappings concurrently. The abovementioned bug occurs pretty soon (500.000 operations), the read thread hangs around for 5-10 seconds and gets fixed by the writer thread some time later. I've measured that a read operation lasts on average 0.01-0.02 milliseconds. So if one of the threads detects that last execution lasted longer then 5 seconds it is safe to say that this thread was hanging and got fixed by another writer. Speaking of that, we could probably reproduce it on the production servers by not restarting them, and leting them run some hours or days instead (maybe as long as the user is still online, I don't know) and hope they will get fixed. However this is not really a solution. The reason I can't reproduce the infinite loop, is that I can't stop the writers in time. Performing thousands of writes per second in multiple threads makes it hard to stop all writers at the same point, before they unintentionally fix the reader. Still, I assume, I have a good chance that an infinite loop happens on the production server if the user leaves the server, and no further write operations are performed on his session. -- 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]
