On Friday 08 October 2010 9:16:47 am Benson Margulies wrote: > On the wire, that blob has to travel as a MIME part. And there might > be several such MIME parts. Unless you traffic in interceptors, as far > as I know, the entire content will be pulled into memory, unless it's > very big, in which case it ends up in a temp file. CXF can't just > leave the socket that the data is arriving on sitting there waiting > for you to read the stream on the data handler.
Actually, if it's the last MIME part that was asked for (that's a key point), it WILL stream right off the socket. It won't get buffered. If something causes it to have to search for another mime part (like asking the attachment collection it's size), then it would get buffered, but for a normal "single attachment through JAXB or SWA" type case, it would stream. Spent a lot of time getting that working correctly. :-) > 2010/10/8 Jimi Hullegård <[email protected]>: > > I have set up a simple webservice for testing, where the object to > > transfer contains a bunch of simple fields, and then a DataHandler for > > some binary data (a Blob, actually). It works just fine, and some test > > with large files (500MB) proved to me that it really works without > > having the entire data in memory on the server or on the client. > > > > But then I realised that in most use cases, we will not need this binary > > data, so on the client side we will not read from the InputStream of the > > DataHandler. But can that cause any problem? Because when I think about > > it I don't really know how CXF handles this DataHandler. Maybe it > > assumes that the entire content of the DataHandler InputStream will be > > sent, and that it keeps the connection open until the client has > > finished reading, or until some timeout. Or maybe it assumes the > > opposite, that it can close the connection after it has transfered the > > "normal" data, and then open a new connection if the client starts to > > read from the InputStream of the DataHandler. > > > > If it is something like the first scenario, that what can I do to > > transfer this object the right way, without having to read the > > InputStream? I can't find any information about this in the > > documentation. Really, with the way HTTP works, there isn't much you CAN do. The best you can do is grab the input stream and close it immediately. We'll call the close on the underlying http input stream. What happens then I'm unsure of. It COULD do one of two things: 1) Keep reading till the end of the stream anyway so the connection can be re- used with the Keep-Alive things. 2) Close the underlying socket which would result in a SocketClosed type exception on the server side. This would close the connection entirely so a future connection would require a new socket and everything to be re-setup. -- Daniel Kulp [email protected] http://dankulp.com/blog
