Jetty Continuations (Long poll) and release of request object

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Jetty Continuations (Long poll) and release of request object

ehsgkat
This post has NOT been accepted by the mailing list yet.
hi,

my application has a scenario where my clients use long poll to subscriber for some events.
The long poll is sufficed by Jetty, our only problem is the amount of memory we use per connection. On an average when i do a standalone test storing continuations objects in a datastructure for a later use the memory usage per request is around 13K bytes.
Though the same code if also starts reading the input request (which is a JSON post, with approximately 150 characters ), the memory usage per connetion goes to around 50K. Which means as an example 100K connections took 1.3 Gig of RAM without reading input payload, starts to take 5G plus when i read a payload of 150 characters.

after more analysis i found, that the HTTPRequest object and corresponding inputstream holds the info read from the stream and that is what raises the size.

Am trying to understand if there are ways that i can release the request object memory as i have already read the input.

I have some details on the following thread, which i would avoid copying again

http://stackoverflow.com/questions/13664743/jetty-continuation-and-unexplainable-memory-usage-pattern

in my view, the user of continuations should have a choice to suspend continuations and saying that request object resources shall be released ( especially the byte []s / other datastructures related to reads on input stream).
This overuse of memory till contiuations are complete are just an overhead....

(am i missing something or asking for too much? )

rgds