Thanks for the insight, Oleg. I was not aware that the key to repeatability was knowing the length in advance. That seems to suggest we could have an API that accepted the stream and a length to produce a repeatable multipart entity.
As for converting the URLs to files, I'm not sure there is a clean way to do that since we are running in a servlet container without access to the file system. I'll do some research and see if there is a means of making this conversion that I'm not currently aware of. Joe On Thu, Dec 18, 2014 at 3:17 AM, Oleg Kalnichevski <[email protected]> wrote: > > On Wed, 2014-12-17 at 17:37 -0600, Joe Barnes wrote: > > Hello community! > > > > My team is faced with a problem where we need to send a resource that is > > available via URL (more precisely, it is on our classpath). We are > running > > in a servlet container, so we don't have direct access to the file > system. > > I completely understand why the chunks are marked as "Non-repeatable" > when > > using an InputStream, because in general they are not necessarily > > repeatable. > > > > Currently we are reading the URL in its entirety to memory, then shipping > > it off. This is quite burdensome because of the size of the resources > and > > number of concurrent users we can expect. The best we can do is create a > > singleton of the value in memory, but it still is expensive for something > > which could certainly be streamed. > > > > Are there any approaches we can utilize to send a URL's contents to a > > multi-part while being repeatable without reading it entirely into > memory? > > > > Thanks! > > Joe > > Joe, > > Presently MultipartFormEntity cannot be repeated if length of any of its > parts is unknown, which is the case with body parts backed by a > InputStream or a URL. In your particular case, however, given that URLs > represent local resources you should be able to convert them to File > instances and thus make their length known in advance. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
