On Wed, 2010-02-17 at 08:50 +0100, Francesco Toro XB wrote:
> Thank you Oleg for the answer.
> 
> You're right, into the simple HttpServer application I'm testing it makes no 
> sense to buffer request body. 
> The problem is that I introduced this buffering statement becouse We are 
> planning to build an application that must parse xml bodies incoming inside 
> http request as soon as possible. So I NEED to buffer the incoming body in 
> memory in order to start parsing it and retrieving the information I need.
> 
> The only solution is to increase the total heap associated to my application?
> 

Buffering large amounts of data in memory will leave your application
prone to out of memory conditions especially if the load increases
unexpectedly. 

You should really rethink the overall architecture of your architecture.
When working with large XML data sets, you should seriously consider
processing them by feeding the request input stream directly to the SAX
parser. If for whatever reason your application needs to parse the same
request multiple times, consider saving the request body in a temp file.

Hope this helps

Oleg 


> Thanks again,
> 
> Francesco.
> 
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:[email protected]] 
> Sent: lunedì 15 febbraio 2010 20.22
> To: HttpClient User Discussion
> Subject: Re: HTTPCORE memory leak on simple server implementation
> 
> Francesco Toro XB wrote:
> > Hi All,
> > 
> 
> ...
> 
> 
> >             if (request instanceof HttpEntityEnclosingRequest) {
> >                 HttpEntity entity = ((HttpEntityEnclosingRequest) 
> > request).getEntity();
> >                 byte[] entityContent = 
> > EntityUtils.toByteArray(entity);
> 
> Francesco
> 
> What is the point of buffering the entire request body in memory? This makes 
> no sense. If request body is 22 MB and the total heap is 200 MB if may take 
> as few as 5 concurrent requests to cause the process run out of memory on the 
> heap.
> 
> DO NOT buffer incoming requests in memory and the problem will go away.
> 
> Oleg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to