RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Guys, I use a synchronised HashMap like Chuck is suggesting here and I have to say it's absolutely fine. We have an application here with hundreds of users logging in and doing stuff concurrently and I have seen no negative impact on performance. So basically you either do that or use something like a Vector. /Arup -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: 08 September 2005 04:51 To: Tomcat Users List Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() From: Len Popp [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() Inside Tomcat, references to the hashmap in question are synchronized on the hashmap object itself, StandardSession.attributes (see org.apache.catalina.session.StandardSession). Except it doesn't appear to be done consistently. The existing synchronization in 5.5.9 protects against concurrent updates, but not against a retrieval that happens at the same time as an update. I don't understand the rationale behind this experiment that removed the synchronization, since uncontended object locking has very little performance impact in modern JVM/JIT implementations. Removal of the synchs would allow concurrent retrievals, but would the frequency of that warrant the reduction in robustness? So if I want to *safely* call session.setAttribute or session.getAttribute I have to make sure the calls are synchronized on session.attributes. Actually no - if you can find _all_ the events that can trigger references or udpates to session attributes, you can synchronize on any object you like. The synchronize blocks internal to Tomcat then become redundant, but they cause no harm. Another option (as suggested by the HashMap javadoc) is to modify StandardSession to use a HashMap wrappered by Collections.synchronizedMap(). No idea what kind of performance impact that would have, but at least it would limit the changes needed to just one place in one file. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
On 9/7/05, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Len Popp [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() So if I want to *safely* call session.setAttribute or session.getAttribute I have to make sure the calls are synchronized on session.attributes. Actually no - if you can find _all_ the events that can trigger references or udpates to session attributes, you can synchronize on any object you like. The synchronize blocks internal to Tomcat then become redundant, but they cause no harm. It would take me quite a while to look at all the possible code paths inside Tomcat to figure that out. :-( Another option (as suggested by the HashMap javadoc) is to modify StandardSession to use a HashMap wrappered by Collections.synchronizedMap(). No idea what kind of performance impact that would have, but at least it would limit the changes needed to just one place in one file. - Chuck That would be easier, but I was hoping I wouldn't have to use a hacked version of Tomcat. Thanks for your explanations. -- Len - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
coming late to the party with: http://blogs.opensymphony.com/plightbo/archives/000175.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
On 9/7/05, GB Developer [EMAIL PROTECTED] 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). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
--- Remy Maucherat [EMAIL PROTECTED] wrote: On 9/7/05, GB Developer [EMAIL PROTECTED] 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). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nothing shocking about HashMap. It becomes very hard to rely on complex Objects if they are not being synchronized when modified especially something like thismultiple 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
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:[EMAIL PROTECTED] Gesendet: Mittwoch, 7. September 2005 21:11 An: Tomcat Users List Betreff: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() --- Remy Maucherat [EMAIL PROTECTED] wrote: On 9/7/05, GB Developer [EMAIL PROTECTED] 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). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nothing shocking about HashMap. It becomes very hard to rely on complex Objects if they are not being synchronized when modified especially something like thismultiple 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
From: Wade Chandler [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() 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. Or the HashMap may have been left in an indeterminate state due to concurrent unsynchronized set requests at some point in the past. A single get can later stumble into the situation and hang in a loop. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
--- Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Wade Chandler [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() 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. Or the HashMap may have been left in an indeterminate state due to concurrent unsynchronized set requests at some point in the past. A single get can later stumble into the situation and hang in a loop. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Exactly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
OK, so how do I fix this problem in my application? I can't figure it out. Inside Tomcat, references to the hashmap in question are synchronized on the hashmap object itself, StandardSession.attributes (see org.apache.catalina.session.StandardSession). So if I want to *safely* call session.setAttribute or session.getAttribute I have to make sure the calls are synchronized on session.attributes. But I can't access session.attributes - it's a protected field and I don't see a method that returns it. So I cannot make my setAttribute calls synchronize properly with Tomcat's code. I don't see how I can work around this. Am I missing something? Or do the Tomcat guys have to fix it? -- Len On 9/6/05, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Arup Vidyerthy [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() Does this mean that all session.setAttribute() and session.getAttribute() should always be synchronised That's the conclusion I'm reluctantly coming to, if there is the possibility of multiple threads updating the same session simultaneously. Luckily, you would think that most operations would really be request, not session, related. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
From: Len Popp [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get() Inside Tomcat, references to the hashmap in question are synchronized on the hashmap object itself, StandardSession.attributes (see org.apache.catalina.session.StandardSession). Except it doesn't appear to be done consistently. The existing synchronization in 5.5.9 protects against concurrent updates, but not against a retrieval that happens at the same time as an update. I don't understand the rationale behind this experiment that removed the synchronization, since uncontended object locking has very little performance impact in modern JVM/JIT implementations. Removal of the synchs would allow concurrent retrievals, but would the frequency of that warrant the reduction in robustness? So if I want to *safely* call session.setAttribute or session.getAttribute I have to make sure the calls are synchronized on session.attributes. Actually no - if you can find _all_ the events that can trigger references or udpates to session attributes, you can synchronize on any object you like. The synchronize blocks internal to Tomcat then become redundant, but they cause no harm. Another option (as suggested by the HashMap javadoc) is to modify StandardSession to use a HashMap wrappered by Collections.synchronizedMap(). No idea what kind of performance impact that would have, but at least it would limit the changes needed to just one place in one file. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
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 -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 400 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]
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.
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?
But how can that happen? a JVM / Core Api bug?
public abstract class UserId implements Serializable{
public abstract String getPlainPresentation();
public boolean equals(Object anotherObject){
return anotherObject instanceof UserId ?
((UserId)anotherObject).getPlainPresentation().equals(getPlainPresentation()):
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; ifragmentationDepth; 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 400 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
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
-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; ifragmentationDepth; 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 400
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
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
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.
Ok understood, just to be sure. In a util class I do following:
public void addBeanToSession(HttpServletRequest req, String beanName,
Object beanValue){
HttpSession session = req.getSession();
synchronized(session){
session.setAttribute(beanName, beanValue);
}
}
and replace all req.getSession().setAttribute(beanName, beanValue) in
code with the call to this method (same for remove) and I've solved my
problem?
thanx for your help
regards
Leon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() and replace all req.getSession().setAttribute(beanName, beanValue) in code with the call to this method (same for remove) and I've solved my problem? Unfortunately, you also need to change the places that retrieve attributes from the Session, since the hash map is in a state of flux during the setAttribute() invocations. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Guys, I have been watching this thread with interest. Does this mean that all session.setAttribute() and session.getAttribute() should always be synchronised (for instance, inside a servlet or struts action) provided the same hashmap is accessed by say more than one servlet/struts action? Kind regards... Arup Vidyerthy. -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 15:54 To: Tomcat Users List Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() and replace all req.getSession().setAttribute(beanName, beanValue) in code with the call to this method (same for remove) and I've solved my problem? Unfortunately, you also need to change the places that retrieve attributes from the Session, since the hash map is in a state of flux during the setAttribute() invocations. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
:
request.getSession().removeAttribute(key);
break;
case PageContext.REQUEST_SCOPE :
request.removeAttribute(key);
break;
default :
throw new RuntimeException(Unknown scope: +
scope);
}
}
public static void addBeanToSessionSafe(HttpServletRequest request,
String key, Object value) {
HttpSession session = request.getSession();
if (logger!=null)
logger.debug(addBean + key + to SESSION_SCOPE,
value= + value);
synchronized(session){
session.setAttribute(key, value);
}
}
public static void removeBeanFromSessionSafe(HttpServletRequest
request, String key){
HttpSession session = request.getSession();
if (logger!=null)
logger.debug(removeBean + key + from
SESSION_SCOPE);
synchronized(session){
session.removeAttribute(key);
}
}
public static Object getBeanFromSessionSafe(HttpServletRequest request,
String key) {
HttpSession session = request.getSession();
Object value = null;
synchronized(session){
value = session.getAttribute(key);
}
if (logger!=null)
logger.debug(getBean + key + from SESSION_SCOPE:
+value);
return value;
}
}
On Tue, 2005-09-06 at 16:41 +0100, Arup Vidyerthy wrote:
Guys,
I have been watching this thread with interest.
Does this mean that all session.setAttribute() and session.getAttribute()
should always be synchronised (for instance, inside a servlet or struts
action) provided the same hashmap is accessed by say more than one
servlet/struts action?
Kind regards...
Arup Vidyerthy.
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: 06 September 2005 15:54
To: Tomcat Users List
Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
and replace all req.getSession().setAttribute(beanName, beanValue) in
code with the call to this method (same for remove) and I've solved my
problem?
Unfortunately, you also need to change the places that retrieve attributes
from the Session, since the hash map is in a state of flux during the
setAttribute() invocations.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
-
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]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
From: Arup Vidyerthy [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() Does this mean that all session.setAttribute() and session.getAttribute() should always be synchronised That's the conclusion I'm reluctantly coming to, if there is the possibility of multiple threads updating the same session simultaneously. Luckily, you would think that most operations would really be request, not session, related. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
On Tue, 2005-09-06 at 11:00 -0500, Caldarale, Charles R wrote: From: Arup Vidyerthy [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get() Does this mean that all session.setAttribute() and session.getAttribute() should always be synchronised That's the conclusion I'm reluctantly coming to, if there is the possibility of multiple threads updating the same session simultaneously. Luckily, you would think that most operations would really be request, not session, related. clearly, 90% are in the request or even page scope, but 10% you have in session (like locale, user related info like authentification or granted permissions) are needed on each request (at least we do :-)) on the other hand it encourages me to work sessionless in the future... (*dreaming*) regards Leon - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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]
Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
It seems possible to be that one user simply pressing the reload button a few times quickly while the same page is not yet loaded can cause sync problems to his own session; and you can't control the user. Err... does anybody have a replacement class for HttpServlet ? A simple access wrapper class would only protect co-operative users of it, a replacement for HttpServlet would protect all users and persist across requests. It seems like the general case needs to use one, while only performance optimized case would be able to make do with the current one. While I agree developers should have access to low level classes to get raw performance, I don't agree that the normal case should expose such a basic design error. HTTP is designed to specifically allow simultaneous requests to be processed at the same time. With a replacement class for HttpServlet you'd be better of using a ReadWriteLock to protect access, which allows for threading of the common read access case. Tut, tut. Arup Vidyerthy wrote: I have been watching this thread with interest. Does this mean that all session.setAttribute() and session.getAttribute() should always be synchronised (for instance, inside a servlet or struts action) provided the same hashmap is accessed by say more than one servlet/struts action? -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
