On Wed, Oct 05, 2011 at 01:25AM, Oleg Kalnichevski wrote: > On Tue, 2011-10-04 at 15:52 -0700, Konstantin Boudnik wrote: > > Hello > > > > Firstly, I'd like to thank this group of people for outstanding job in > > development Java layer for generic HTTP: very nicely and conveniently done! > > > > Now, once I am done with being nice I have a question ;) Here's the use case > > where I don't see a good workaround for. > > > > We have that piece of functionality in our app. where we need to grab a > > little > > sample of a web.object (e.g. a file somewhere on a web-server side). Once > > the > > sample is obtained the software isn't interested in the rest of the content > > and would like to close the InputStream (actually it happens to be > > ContentLengthInputStream) from that object. The situation we are in is that > > we > > can't set ContentLength on the client side and the connection is forcefully > > kept alive from the server side. > > > > The objects (files) are pretty large (10s or 100s of Mb) and we don't want > > to > > keep downloading the rest of the content every time we need to sample. By > > looking into the code of that class above I see that close() method keeps > > pumping the data until ContentLength is reached. This seems to be > > troublesome > > in cases when the app's code is rapidly opens a whole bunch of connections > > to > > different remote objects for the sampling purposes and then trying to close > > those. However, close() doesn't do any real closing of the socket input so > > data transfer continues and I might end up with OOME ;( > > > > Considering above restrictions is their any advisable solution for the > > problem > > I am facing? I believe patching ContentLengthInputStream might be pretty > > tricky because ContentLengthInputStream can't actually close > > SessionInputBuffer. > > > > Any hints would be highly appreciated! > > Konstantin > > Per default HttpClient always makes an attempt to keep a persistent > connection alive. This is the reason for #close() method of > ContentLengthInputStream always reading from the underlying connection > until the end of the message. One can use HttpUriRequest#abort() to > immediately shut down the underlying connection (if allocated) and > remove it from the connection pool. > > Hope this helps > > Oleg
Thanks Oleg - this seems like a reasonable approach. Let me see if this solves our situation. With regards, Cos > --------------------------------------------------------------------- > 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]
