tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Date Wed, 07 Sep 2005 19:10:40 GMT
--- 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


Mime
View raw message