On Thursday 20 January 2011 7:30:09 am Benson Margulies wrote: > Dan, > > Thanks. How embarassing. > > Does the JAX-WS spec give us any leeway in offering a feature to close > up these streams by magic when the service function returns? Aside, of > course, from the possibility that someone wants to hang onto one.
Well, JAX-WS RI get's around it by not streaming. The inputstream would be a ByteArrayInputStream in this case. We could offer a feature to do the same. Stick the nice 100MB attachments in memory. Problem solved. :-) The other option could be to wrapper it with an InputStream with a finalize method that would call close. The GC could potentially handle it, but I'm actually a bit surprised it isn't already handling it. That said, finalize methods do hurt performance in some cases. Dan > > --benson > > On Wed, Jan 19, 2011 at 2:35 PM, Daniel Kulp <dk...@apache.org> wrote: > > On Wednesday 19 January 2011 1:56:35 pm Benson Margulies wrote: > >> Ian has cooked up test case for our woes with with wierd timeouts with > >> MTOM. Let us know if we can help further. > >> > >> https://issues.apache.org/jira/browse/CXF-3259 > > > > The client isn't closing the streams. If you do: > > > > DataHandler dh = d.getContentBlob("bogusDocID", "BogusBlobID"); > > dh.getInputStream().close(); > > > > then it runs to completion. Basically, the server has tried to send > > some data back to the client. In your case, the 2048 bytes likely fits > > into the socket buffer so from the server sides point of view, data was > > sent. However, the HTTPUrlConnection on the client side hasn't read all > > the data. Thus, the client side cannot reuse the connection and > > creates more connections. Eventually, it runs out of file handles and > > thread pools and such. (example: call "ulimit -n 256" first. Dies > > pretty fast) Also, on the server side, the connections do look idle. > > All data was sent to the client, but no furthur requests have come in > > (since the client cannot reuse the connection) so it closes them. > > > > Basically, if you don't close streams, all hell can break lose. :-) > > > > -- > > Daniel Kulp > > dk...@apache.org > > http://dankulp.com/blog -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
