struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <>
Subject [IMPORTANT] tomcat 5.0.19+ is broken / not useable with struts / your voice needed
Date Wed, 07 Sep 2005 22:05:26 GMT
to whom it may concern
There is a serious bug in tomcat 5. To make it short, if you write to or
read from session (taglibs included) and have a chance that there is more
than one request from same user currently proceeded on the server (and it
can be just a web-page refresh, our beloved F5 key) you are f**ked. 
What happens is that the HashMap where the session attributes are stored got
corrupted, and the in the HashMap points to itself (or start of
the list). Next request to the session.getAttribute results in an endless
loop, and your server has 100% cpu load. 
You can read full bug description at:
What does it mean for us, struts-users? 
If we use the session scope:
1. Struts-taglibs aren't thread-safe.
2. Application that are working under tomcat 4.1 or resin, or probably any
other servlet container will not work under tomcat 5 (or are not reliable).
3. We must forbid users to have multiple browsers open.
4. We can't handle multiple frames or concurrent requests from same user /
5. ... many other examples available.
affected versions: 
If you ever had actions hanging around in
session.getAttribute()/HashMap.get() for hours and don't know why -> it's
your bug.
What can you do:
Please, click the bug link
( and read it ALL
carefully. Decide whether you may or may not be affected by this issue.
If you are affected by this issue, and most of us are affected, log in and
vote for the bug. If you don't have a bugzilla account, but are affected by
this bug: setup a bugzilla account and vote. 
Similar request has been started by Wade Chandler at tomcat-users list.
P.S. One more thing, could struts-developers team supply a patch for tomcat
5.0.x and 5.5.x for download on the struts homepage? surrounding calls to
attributes hashmap with synchronized(attributes){} as it was done in 4.1.x
is sufficent.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message