We're using GF 3.1.2 and on a production site we run out of memory after
about 2 weeks. We're using a program to catch memory leaks and it's giving
us a stack trace here:
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java)
at
com.sun.grizzly.tcp.http11.GrizzlyRequest.doGetSession(GrizzlyRequest.java:2270)
at
com.sun.grizzly.tcp.http11.GrizzlyRequest.getSession(GrizzlyRequest.java:2232)
at
com.sun.grizzly.http.servlet.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:986)
at
com.sun.grizzly.http.servlet.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:1009)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:267)
<our code>
A coworker found this code, but the line numbers look off:
http://grepcode.com/file/repo1.maven.org/maven2/com.sun.grizzly/grizzly-utils/1.9.36/com/sun/grizzly/tcp/http11/GrizzlyRequest.java#2241
I don't fully understand this code, but wouldn't this "sessions" object
grow infinitely as long as the requestedSessionId is somewhat unique? If
it's unique, it'll never get to that line to call sessions.remove() and the
session will stay in there forever?
To word it another way: What ensures that doGetSession() is called that
final time to make sure the session is removed from the "sessions" object?
If this is a (known) memory leak, are there any work arounds?
--
Thanks,
Dan
--
CONFIDENTIALITY NOTICE: The information contained in this electronic
transmission may be confidential. If you are not an intended recipient, be
aware that any disclosure, copying, distribution or use of the information
contained in this transmission is prohibited and may be unlawful. If you
have received this transmission in error, please notify us by email reply
and then erase it from your computer system.