On Friday 08 October 2010 10:29:13 am Jimi Hullegård wrote: > Daniel Kulp [[email protected]] wrote: > > 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. :-) > > But how can I specify the order of the MIME parts? Also, what is a "normal" > JAXB/SWA attachment? My entity has a DataHandler field, where the > get-method looks like this: > > @Transient > @XmlMimeType("application/octet-stream") > public DataHandler getDataHandler() { > return dataHandler; > } > > And the endpoint looks like this: > > <jaxws:endpoint id="documentManager" > implementor="#interceptedDocumentManager" address="/DocumentManager"> > <jaxws:properties> > <entry key="mtom-enabled" value="true" /> > </jaxws:properties> > </jaxws:endpoint> > > Could this cause the binary data to be buffered in its entirety in some > cases?
In most cases, that will not buffer the data. The cases where it would involve: 1) Multple attachments. Not your case. You only have one. 2) Turning on schema validation. Due to a "bug" in JAXB, if schema validation is on, the schema validator consumes the stream. Thus, we buffer. Again, not your case. 3) SAAJ interceptors. SAAJ also requires buffering them. Again, not your case. 4) JAX-WS handlers - relates to SAAJ. Again, not your case. Thus, you should be all set. > > 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. > > OK. Well, since I will refactor my code and divide the entity into two (one > for metadata, and one for binary data), I won't have to handle any > unwanted binary data. But I'm still wondering what happens if I request > the binary data entity, but then for some reason never touch the > InputStream (ie not reading from it, and not closing it. Considering the > setup above, what will happen? Will the connection linger for a while > before it times out? Can it cause some negative side effects, like leaking > memory? On the client side, I don't think it would really cause an issue. Eventually, the connection would get garbage collected and cleaned up and such. There may be a performance issue if you use the client to talk back and forth with the server quite a bit as that particular connection would not be able to be used for keep-alive scenarios. The server side is slightly more problematic. The server will be trying to write to that socket. If the client isn't reading, the server will block. Eventually, the socket will timeout (your app server or container or whatever usually have somesort of timeout control) and the server will throw an Exception and the thread will free up, but for that period of time, that thread will not be available to process additional requests. -- Daniel Kulp [email protected] http://dankulp.com/blog
