cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Promised test case for MTOM-related hangs
Date Thu, 20 Jan 2011 15:41:25 GMT
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 <dkulp@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
> > dkulp@apache.org
> > http://dankulp.com/blog

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message