cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Promised test case for MTOM-related hangs
Date Thu, 20 Jan 2011 16:22:06 GMT
I wasn't clear.

We *could* define the model to be

try {
   call_function_in_sib();
} finally {
   stream.close();
}

but that would not work for anyone inclined to hang onto the stream
like grim death. The gc does clean this up, but if you have lots of
VM, it has no reason to be in a hurry to finalize the streams.

On Thu, Jan 20, 2011 at 10:41 AM, Daniel Kulp <dkulp@apache.org> wrote:
> 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