On 4/25/07, Reich, Matthias <[EMAIL PROTECTED]> wrote:
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?
Processors are only recycled when the IO layer gets an event (read,
disconnect, timeout), and if:
- the event is a non timeout error
- the event is closed by the servlet
- the event has been closed asynchronously
If the client is sitting there without sending any data (if it
disconnects, it becomes either a read event or an error/disconnect
event, so it's the same), then you have to wait for the timeout (which
can be set per event with the NIO connector - this is not doable at
this time for the APR connector).
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
