tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <struts_u...@anotheria.net>
Subject Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Date Wed, 07 Sep 2005 19:19:51 GMT
Check the bug:

http://issues.apache.org/bugzilla/show_bug.cgi?id=36541


And yes, the HashMap explicitely prohibits the way it's been used by tomcat
5 StandardSession in it's javadoc.




> -----Ursprüngliche Nachricht-----
> Von: Wade Chandler [mailto:hwadechandler-apache@yahoo.com] 
> Gesendet: Mittwoch, 7. September 2005 21:11
> An: Tomcat Users List
> Betreff: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
> 
> --- Remy Maucherat <remy.maucherat@gmail.com> wrote:
> 
> > On 9/7/05, GB Developer
> > <gb1071nx@globallyboundless.com> wrote:
> > > coming late to the party with:
> > > 
> > >
> >
> http://blogs.opensymphony.com/plightbo/archives/000175.html
> > 
> > I had read your blog when you originally posted it, and 
> thought it was 
> > the most interesting blog I had read in months. IMO, given 
> the average 
> > size of the array in a typical hashmap (very small), they 
> should have 
> > added a robstness check (typically, e != e.next).
> > 
> > --
> > xxxxxxxxxxxxxxxxxxxxxxxxx
> > Rémy Maucherat
> > Developer & Consultant
> > JBoss Group (Europe) SàRL
> > xxxxxxxxxxxxxxxxxxxxxxxxx
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tomcat-user-help@jakarta.apache.org
> > 
> > 
> Nothing shocking about HashMap.  It becomes very hard to rely 
> on complex Objects if they are not being synchronized when 
> modified especially something like this....multiple lines of 
> code not being synchronized....  Any map which is being put 
> from multiple threads should be synchronized and anything in 
> an "inconsistant" state is a bad idea period.  The hashtable 
> shouldn't be resizing anything when simply calling get..and 
> per the code it doesn't.  A put must be called for a resize 
> to take place no if and or but about it, so it's not just a 
> getAttribute call or even 50 million of them alone going to 
> cause HashMap to lock, but rather the Object being in an 
> intermediate step when get is called.  If you can use a 
> synchronized HashMap and the problem not occur then the 
> problem certainly comes from modifying the map and reading 
> from different threads at the same time which makes sense 
> when looking at the code and the javadoc statement(Directly 
> from the javadocs):
> 
> Note that this implementation is not synchronized. If 
> multiple threads access this map concurrently, and at least 
> one of the threads modifies the map structurally, it must be 
> synchronized externally. (A structural modification is any 
> operation that adds or deletes one or more mappings; merely 
> changing the value associated with a key that an instance 
> already contains is not a structural modification.) This is 
> typically accomplished by synchronizing on some object that 
> naturally encapsulates the map. If no such object exists, the 
> map should be "wrapped" using the Collections.synchronizedMap 
> method. This is best done at creation time, to prevent 
> accidental unsynchronized access to the map: 
> 
>  Map m = Collections.synchronizedMap(new HashMap(...));
> 
> Should be enough to explain the issue and why synchronization 
> should be used.  I haven't looked at the Tomcat code, but why 
> would a Session not use synchronized maps?  In my opinion 
> it's not a bug in HashMap as it's up front about it not being 
> synchronized.  To fix the original posters current situation 
> they should be able to synchronize on an object when 
> accessing the session...you'll just have to track down all of 
> your calls which are setting and getting attributes and 
> synchronize the code.
> 
> My 2 cents
> 
> Wade
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message