Re: Memory Leak caused by ThreadLocalMap - The suspect is com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet

The current implementation of com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet uses two instances of ThreadLocal to wrap the HttpServletRequest and HttpServiceResponse objects. (both are not static; couldn't see any calls to remove; "this" is in the sychronized block - couple of things that triggered my suspicions).

Did anybody faced similar issues?

Don't think so but it concerned me so I took a look ... seems ok but...

Every doPost it will call

if (perThreadRequest == null) {

perThreadRequest = new ThreadLocal<HttpServletRequest>();

} if (perThreadResponse == null) {       perThreadResponse = new ThreadLocal<HttpServletResponse>();     } So that would be one instance of each per servlet right!?! Also per doPost it calls: try {     perThreadRequest.set(request);     perThreadResponse.set(response);         processPost(request, response); ...     } finally {       // null the thread-locals to avoid holding request/response       //       perThreadRequest.set(null);       perThreadResponse.set(null); } So that should clear the response, request right!?! I can't see an issue with AbstractRemoteServiceServlet but ... am I missing something? Well OK I don't understand why the call is perThreadRequest.set(null) and NOT .remove() remove()            Removes the current thread's value for this thread-local variable set(T value)            Sets the current thread's copy of this thread-local variable to the specified value.

  Are the 400.000 entries null and if so is that taking memory???

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.