You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2011/01/19 19:56:35 UTC
Promised test case for MTOM-related hangs
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
Re: Promised test case for MTOM-related hangs
Posted by Benson Margulies <bi...@gmail.com>.
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 <dk...@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 <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
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: Promised test case for MTOM-related hangs
Posted by Daniel Kulp <dk...@apache.org>.
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
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Promised test case for MTOM-related hangs
Posted by Benson Margulies <bi...@gmail.com>.
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
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: Promised test case for MTOM-related hangs
Posted by Daniel Kulp <dk...@apache.org>.
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