Salut,
FredrikJ wrote:
> I have been implementing a Comet based solution recently and I noticed a
> memory pattern that looked like a memory leak. After some trial and error I
> ended up with a very simple servlet:
>
>
> public class SimpleServlet extends HttpServlet {
>
> @Override
> public void init(ServletConfig config) throws ServletException {}
>
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse resp)
> throws ServletException, IOException {
> try {
> Thread.sleep(200);
> } catch (InterruptedException e) {}
>
> PrintWriter writer = resp.getWriter();
> writer.write("World's Simplest OOM Servlet");
> writer.flush();
> }
>
> }
>
>
> The memory-pattern not entirely deterministic, but the basic behavior is
> like this:
>
> - If I run requests against the servlet with a default connector (i.e. I
> have not specified cometSupport in domain.xml), I get no surprises. The
> memory churn is very low and all memory is recovered after the responses
> have been sent.
>
> - If I add <property name="cometSupport" value="true"/> to the domain.xml
> for the http connector, then memory goes up drastically and then stays up.
> For 500 requests the old gen memory goes up from about 50MB to 130MB. The
> memory is never recovered, I have waited for timeouts and repeatedly forced
> GC's.
>
> Note: The memory issue only occurs when I have a substantial delay
> (Thread.sleep) in the servlet. If I return the response immediately then I
> do not see this behavior.
>
> My first reactions was that it was an obvious memory leak coupled to request
> handling with a certain timeframe, but it also seems that this only occurs
> for the first batch I run against the server. For instance, if I apply 500
> requests from JMeter then I will have roughly 130MB sitting around in old
> gen. But any consecutive 500 requests does not further increase the static
> old gen allocation.
See:
> Tag: SJSAS91_FCS_BRANCH
> User: jfarcand
> Date: 2009-03-31 00:15:32+0000
> Modified:
> glassfish/appserv-http-engine/src/java/com/sun/enterprise/web/connector/grizzly/comet/CometContext.java
>
> Log:
> More fix for http://bt2ws.central.sun.com/CrPrint?id=6790295 (Internal bug)
> ("OOM when compression enabled and commetSupport=true")
>
> The CometContext API cannot change its method signature as it breaks compatibility.
>
> Kudo to Chee-Weng Chea for the analysis
>
> + ALL QL passed
(the bug was filled internally)
Yes there were a memory leak with 2.x/ Grizzly 1.0 (not 1.9.x). I can
send you a patch if you are interested.
Thanks
-- Jeanfrancois
>
> A heap dump reveals that after 500 requests I usually have about 450
> requests, responses and sessions in the heap. If I run 1000 requests
> initially I end up with about 600. These seem to never be garbage collected.
>
> Any clarifications on why I am seeing this memory pattern would be very much
> appreciated since I am currently very reluctant on putting Comet into
> production with this type of behavior.
>
> Note 2: I am currently using Glassfish 2.1.
>
>
>