So far, I have the feeling that I am the only one who has seen these memory leaks with asynchronous Comet responses.
I tried with a number of variations, e.g. - let the browser wait for 500 millis before sending the next poll after receiving a result - keep the events queued in the serverfor at least 500 millis before sending the response - modify synchronization and the places where I invoke event.close() - tried with connector attribute maxKeepAliveRequests="-1" and maxKeepAliveRequests="2" but the effect is always the same. Thus, I doubt that it is really 'wrong' usage of the interfaces, and others should have seen similar effects. Has anyone out there run an application with browsers as clients and with asynchronous responses for a longer time without loosing memory? Or am I the only one so far working on such a scenario? Matthias -----Original Message----- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 3:11 PM To: Tomcat Users List Subject: Re: Memory Leak with Comet On 4/25/07, Reich, Matthias <[EMAIL PROTECTED]> wrote: > First I ran Tomcat with a single connector with attribute maxThreads=20, > and started it with -Xmx10m. > In the dump I saw 103 instances of class > org.apache.coyote.http11.Http11AprProcessor and the same number of all > the attached objects like Request, Response ... This basically means what I said: the connections and their associated processors are never properly closed and recycled for some reason. Rémy --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
