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. --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 >
