tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Date Thu, 08 Sep 2005 16:48:00 GMT
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 struts_user@anotheria.net  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message