> -----Original Message-----
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 06, 2005 9:03 AM
> To: Tomcat Users List
> Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
> 
> On Tue, 2005-09-06 at 08:47 -0400, Larry Isaacs wrote:
> > I have seen instances of a HashMap whose entries got circularly 
> > linked, I assume, due to updates which where not thread safe.
> > Any thread using a get() on such a HashMap will spin 
> forever chasing 
> > its tail.
> > 
> > Cheers,
> > Larry
> 
> Could be possible since we also have increasing load (until 
> idle time goes to zero) on those machines.... but...
> we are putting only pretty simple objects like Locale or an 
> userId object. 

I don't think it is a matter of how simple the object, but how
it is being stored in the session.

> If I understand you correctly your scenario is:
> HashMap Entry has a linked list of X entries at one position 
> and entry[Y] is poiting to the first entry instead of next or null?

Correct.

> But how can that happen? a JVM / Core Api bug?

The error is likely in webapp code, since the Servlet spec leaves
it up to the webapp to implement thread safe setting and update of
session objects.  I haven't researched the HashMap source code to
see exactly how this situation can come about, so I can't say
exactly what to look for.  Thus, the not terribly helpful advice
is to examine for thread safety each location where the session is
written.

Cheers,
Larry

> 
> 
> public abstract class UserId  implements Serializable{
> 
>       public abstract String getPlainPresentation();
>       
>       public boolean equals(Object anotherObject){
>               return anotherObject instanceof UserId ? 
> 
> ((UserId)anotherObject).getPlainPresentation().equals(getPlain
> Presentation()):
>                       false;
>       }
>       
>       public abstract String[] getFragmentation(int 
> fragementationDepth, int fragmentLength);
>       
>       public String toString(){
>               return getPlainPresentation();
>       }
> }
> 
> public class LongUserId extends UserId implements Serializable{
>       
>       private long value;
>       private transient String cachedStringPresentation; 
>       
>       private static final long serialVersionUID = 
> 451670268366493765L;
> 
>       public LongUserId(long aValue){
>               this.value = aValue;
>       }
>   
>       public int hashCode(){
>               return (int)value;
>       }
>       
>       
>       public boolean equals(Object o){
>               return (o instanceof LongUserId) ? 
>                       ((LongUserId)o).value == value : false;
>       }
>       
> 
>       public String[] getFragmentation(int fragmentationDepth, int
> fragmentLength) {
>               String s = getPlainPresentation();
>               //first ensure our string is long enough.
>               while (s.length()<fragmentationDepth*fragmentLength)
>                       s = "0"+s;
>               
>               int singleLength = fragmentLength;
>               String ret[] = new String[fragmentationDepth];
>               for (int i=0; i<fragmentationDepth; i++){
>                       String fragment = 
> s.substring(i*singleLength, i*singleLength
> +singleLength);
>                       ret[i] = fragment;
>               }
>                
>               return ret;
>       }
> 
>       public String getPlainPresentation() {
>               if (cachedStringPresentation==null)
>                       cachedStringPresentation = ""+value;
>               return cachedStringPresentation;
>       }
> 
> 
> thanx
> Leon
> 
> 
> > 
> > > -----Original Message-----
> > > From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, September 06, 2005 8:31 AM
> > > To: tomcat-user@jakarta.apache.org
> > > Subject: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
> > > 
> > > Hi,
> > > 
> > > This is quite ugly but we are running out of ideas.
> > > 
> > > We are currently experiencing stange behaviour of tomcat 
> (or the VM).
> > > 
> > > Our tomcat hangs (not reproduceable, but probably on parallel 
> > > requests to similar methods) in session.getAttibute():
> > > 
> > > We checked the source code of the HashMap, StandardSession and 
> > > StandardSessionFacade but couldn't find any synchronized methods.
> > > The manager shows the 4 threads hanging since 4000000 
> millis (more 
> > > than an hour).
> > > 
> > > we created a stacktrace with kill - QUIT, here the threads are:
> > > 
> > > 
> > > "http-8580-Processor3" daemon prio=1 tid=0x7cdf11d0
> > > nid=0x3269 runnable [7d7fe000..7d7ff8bc]
> > >         at java.util.HashMap.get(HashMap.java:325)
> > >         at
> > > org.apache.catalina.session.StandardSession.getAttribute(Stand
> > > ardSession.java:975)
> > >         at
> > > org.apache.catalina.session.StandardSessionFacade.getAttribute
> > > (StandardSessionFacade.java:109)
> > >         at
> > > de.friendscout.datingr4.shared.presentation.action.BaseAction.
> > > getUserId(BaseAction.java:653)
> > >         at
> > > de.friendscout.datingr4.onlinearea.presentation.action.BaseOnl
> > > ineAreaAction.getSettings(BaseOnlineAreaAction.java:89)
> > >         at
> > > de.friendscout.datingr4.onlinearea.presentation.action.GetOnli
> > > neUsersAction.doExecute(GetOnlineUsersAction.java:49)
> > > 
> > > 
> > > "http-8580-Processor1" daemon prio=1 tid=0x7d3fa078
> > > nid=0x3269 runnable [7ce7f000..7ce7f8bc]
> > >         at java.util.HashMap.get(HashMap.java:325)
> > >         at
> > > org.apache.catalina.session.StandardSession.getAttribute(Stand
> > > ardSession.java:975)
> > >         at
> > > org.apache.catalina.session.StandardSessionFacade.getAttribute
> > > (StandardSessionFacade.java:109)
> > >         at
> > > de.friendscout.datingr4.shared.presentation.action.BaseAction.
> > > getUserId(BaseAction.java:653)
> > >         at
> > > de.friendscout.datingr4.onlinearea.presentation.action.ShowFil
> > > tersAction.doExecute(ShowFiltersAction.java:42)
> > >         at
> > > de.friendscout.datingr4.shared.presentation.action.BaseAction.
> > > execute(BaseAction.java:316)
> > > 
> > > 
> > > 
> > > "http-8580-Processor24" daemon prio=1 tid=0x7d430200
> > > nid=0x3269 runnable [7e77f000..7e77f8bc]
> > >         at java.util.HashMap.get(HashMap.java:325)
> > >         at
> > > org.apache.catalina.session.StandardSession.getAttribute(Stand
> > > ardSession.java:975)
> > >         at
> > > org.apache.catalina.session.StandardSessionFacade.getAttribute
> > > (StandardSessionFacade.java:109)
> > >         at
> > > de.friendscout.datingr4.shared.presentation.util.RealmUtility.
> > > initRealm(RealmUtility.java:66)
> > >         at
> > > de.friendscout.datingr4.shared.presentation.util.RealmUtility.
> > > initRealm(RealmUtility.java:61)
> > >         at
> > > de.friendscout.datingr4.shared.presentation.controller.Control
> > > lerServlet.doGet(ControllerServlet.java:139)
> > > 
> > > 
> > > My Java knowledge isn't sufficent to explain how 
> something can hang 
> > > in
> > > HashMap.get() since its not synchronized. Neither are the
> > > .getAttribute() methods of the StandardSession or 
> > > StandardSessionFacade.
> > > 
> > > We are using jdk 1.4.2_08-b03, tomcat 5.0.25, struts 1.1, 
> jacorb 2.2 
> > > (night build) on linux/debian/sarge - 3.1 stable.
> > > 
> > > any ideas? anybody?
> > > 
> > > regards
> > > Leon
> > > 
> > > 
> > > 
> > > 
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: 
> [EMAIL PROTECTED]
> > > For additional commands, e-mail: 
> [EMAIL PROTECTED]
> > > 
> > > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to