You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Thibaut Robert <th...@gmail.com> on 2014/11/26 18:02:16 UTC
CxfRs producer: connection not closed
Hi,
When using cxfRs to send a rest message in InOnly mode, Camel do not close
the javax.ws.rs.core.Response object. As we are InOnly, the reponse object
is not passed through the exchange, so the caller can not close it either.
Not calling close on the response maintain the input stream open (and the
associated tcp connection) until it times out (or gc'ed), which is not
desirable.
As a workaround I always use InOut mode and close the response, even if I'm
not interested in the result.
Example (scala code):
val camel = new DefaultCamelContext().createProducerTemplate()
val destination = "http://localhost:1234"
val body = """{"key":"value"}"""
// Leave an open connection
//camel.sendBody("cxfrs:" + destination, body)
// use instead:
camel.requestBody("cxfrs:" + destination,
body).asInstanceOf[Response].close()
Is it possible to change this behaviour in Camel ?
Thanks
--
Thibaut
Re: CxfRs producer: connection not closed
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 01/12/14 09:03, Thibaut Robert wrote:
> Thanks for the clarification, Sergey.
> In the cxfrs producer, I think the Webclient is never closed, and a new one
> is created for each request. Can this be a problem ?
>
I guess it is an optimization issue (more proactive IO resource collection).
FYI, in CXF 3.0.2, a WebClient.close() will be called when a given
instance is garbage collected.
Cheers, Sergey
> On Fri Nov 28 2014 at 18:06:03 Sergey Beryozkin <sb...@gmail.com>
> wrote:
>
>> Hi
>>
>> FYI, no auto-close is done when non-Response types are returned.
>> It was done at some point of time but a lot of side-effects happened as
>> a result, typically with types like Document/etc which may be doing the
>> lazy Input stream reads, etc.
>>
>> The auto-close can be optionally enabled if the user knows it will be
>> safe but the runtime won't do it automatically.
>>
>> Finally, Response.close() closes the input stream only.
>> WebClient.close() can be done to release the underlying HttpConduit
>> instance
>>
>> Thanks, Sergey
>>
>>
>> On 28/11/14 09:58, Thibaut Robert wrote:
>>> I read the code more carefully, and you're right, in the case the
>>> responseClass is provided (response is not an inputstream), it should be
>>> the responsibility of cxf to close the stream.
>>> I wrongly assumed that you use jarxrs client api where you should call
>>> close() after readEntity()
>>>
>>> Thanks for your support !
>>> Thibaut
>>>
>>>
>>> On Fri Nov 28 2014 at 02:17:49 Willem Jiang <wi...@gmail.com>
>> wrote:
>>>
>>>> I think CXF WebClient already take care of it, the response is input
>>>> stream, the user should close it himself.
>>>>
>>>> In camel-http, the http client auto close the connection when it out of
>>>> scope, so we have to copy the stream in camel for the outside usage. But
>>>> it’s the user responsibility to close the stream after consuming the
>> stream.
>>>>
>>>>
>>>> --
>>>> Willem Jiang
>>>>
>>>> Red Hat, Inc.
>>>> Web: http://www.redhat.com
>>>> Blog: http://willemjiang.blogspot.com (English)
>>>> http://jnn.iteye.com (Chinese)
>>>> Twitter: willemjiang
>>>> Weibo: 姜宁willem
>>>>
>>>>
>>>>
>>>> On November 27, 2014 at 10:00:16 PM, thib (thibaut.robert@gmail.com)
>>>> wrote:
>>>>> Thanks, I looked at your fix, seems prefectly fine for my usage. I have
>>>> one
>>>>> question however:
>>>>> Should'nt you close the connection also when responseClass is provided
>> ?
>>>>> (whatever the exchange pattern)
>>>>>
>>>>> I would think that response/connection should be left open only when we
>>>> are
>>>>> able to consume (and close) it from the outside, meaning: responseClass
>>>> is
>>>>> null or Response, and exchange is out capable.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://camel.465427.n5.nabble.
>>>> com/CxfRs-producer-connection-not-closed-tp5759664p5759711.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: CxfRs producer: connection not closed
Posted by Thibaut Robert <th...@gmail.com>.
Thanks for the clarification, Sergey.
In the cxfrs producer, I think the Webclient is never closed, and a new one
is created for each request. Can this be a problem ?
On Fri Nov 28 2014 at 18:06:03 Sergey Beryozkin <sb...@gmail.com>
wrote:
> Hi
>
> FYI, no auto-close is done when non-Response types are returned.
> It was done at some point of time but a lot of side-effects happened as
> a result, typically with types like Document/etc which may be doing the
> lazy Input stream reads, etc.
>
> The auto-close can be optionally enabled if the user knows it will be
> safe but the runtime won't do it automatically.
>
> Finally, Response.close() closes the input stream only.
> WebClient.close() can be done to release the underlying HttpConduit
> instance
>
> Thanks, Sergey
>
>
> On 28/11/14 09:58, Thibaut Robert wrote:
> > I read the code more carefully, and you're right, in the case the
> > responseClass is provided (response is not an inputstream), it should be
> > the responsibility of cxf to close the stream.
> > I wrongly assumed that you use jarxrs client api where you should call
> > close() after readEntity()
> >
> > Thanks for your support !
> > Thibaut
> >
> >
> > On Fri Nov 28 2014 at 02:17:49 Willem Jiang <wi...@gmail.com>
> wrote:
> >
> >> I think CXF WebClient already take care of it, the response is input
> >> stream, the user should close it himself.
> >>
> >> In camel-http, the http client auto close the connection when it out of
> >> scope, so we have to copy the stream in camel for the outside usage. But
> >> it’s the user responsibility to close the stream after consuming the
> stream.
> >>
> >>
> >> --
> >> Willem Jiang
> >>
> >> Red Hat, Inc.
> >> Web: http://www.redhat.com
> >> Blog: http://willemjiang.blogspot.com (English)
> >> http://jnn.iteye.com (Chinese)
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >>
> >>
> >> On November 27, 2014 at 10:00:16 PM, thib (thibaut.robert@gmail.com)
> >> wrote:
> >>> Thanks, I looked at your fix, seems prefectly fine for my usage. I have
> >> one
> >>> question however:
> >>> Should'nt you close the connection also when responseClass is provided
> ?
> >>> (whatever the exchange pattern)
> >>>
> >>> I would think that response/connection should be left open only when we
> >> are
> >>> able to consume (and close) it from the outside, meaning: responseClass
> >> is
> >>> null or Response, and exchange is out capable.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context: http://camel.465427.n5.nabble.
> >> com/CxfRs-producer-connection-not-closed-tp5759664p5759711.html
> >>> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>>
> >>
> >>
> >
>
>
Re: CxfRs producer: connection not closed
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
FYI, no auto-close is done when non-Response types are returned.
It was done at some point of time but a lot of side-effects happened as
a result, typically with types like Document/etc which may be doing the
lazy Input stream reads, etc.
The auto-close can be optionally enabled if the user knows it will be
safe but the runtime won't do it automatically.
Finally, Response.close() closes the input stream only.
WebClient.close() can be done to release the underlying HttpConduit instance
Thanks, Sergey
On 28/11/14 09:58, Thibaut Robert wrote:
> I read the code more carefully, and you're right, in the case the
> responseClass is provided (response is not an inputstream), it should be
> the responsibility of cxf to close the stream.
> I wrongly assumed that you use jarxrs client api where you should call
> close() after readEntity()
>
> Thanks for your support !
> Thibaut
>
>
> On Fri Nov 28 2014 at 02:17:49 Willem Jiang <wi...@gmail.com> wrote:
>
>> I think CXF WebClient already take care of it, the response is input
>> stream, the user should close it himself.
>>
>> In camel-http, the http client auto close the connection when it out of
>> scope, so we have to copy the stream in camel for the outside usage. But
>> it’s the user responsibility to close the stream after consuming the stream.
>>
>>
>> --
>> Willem Jiang
>>
>> Red Hat, Inc.
>> Web: http://www.redhat.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.iteye.com (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>>
>> On November 27, 2014 at 10:00:16 PM, thib (thibaut.robert@gmail.com)
>> wrote:
>>> Thanks, I looked at your fix, seems prefectly fine for my usage. I have
>> one
>>> question however:
>>> Should'nt you close the connection also when responseClass is provided ?
>>> (whatever the exchange pattern)
>>>
>>> I would think that response/connection should be left open only when we
>> are
>>> able to consume (and close) it from the outside, meaning: responseClass
>> is
>>> null or Response, and exchange is out capable.
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.
>> com/CxfRs-producer-connection-not-closed-tp5759664p5759711.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>
>>
>
Re: CxfRs producer: connection not closed
Posted by Thibaut Robert <th...@gmail.com>.
I read the code more carefully, and you're right, in the case the
responseClass is provided (response is not an inputstream), it should be
the responsibility of cxf to close the stream.
I wrongly assumed that you use jarxrs client api where you should call
close() after readEntity()
Thanks for your support !
Thibaut
On Fri Nov 28 2014 at 02:17:49 Willem Jiang <wi...@gmail.com> wrote:
> I think CXF WebClient already take care of it, the response is input
> stream, the user should close it himself.
>
> In camel-http, the http client auto close the connection when it out of
> scope, so we have to copy the stream in camel for the outside usage. But
> it’s the user responsibility to close the stream after consuming the stream.
>
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> Web: http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On November 27, 2014 at 10:00:16 PM, thib (thibaut.robert@gmail.com)
> wrote:
> > Thanks, I looked at your fix, seems prefectly fine for my usage. I have
> one
> > question however:
> > Should'nt you close the connection also when responseClass is provided ?
> > (whatever the exchange pattern)
> >
> > I would think that response/connection should be left open only when we
> are
> > able to consume (and close) it from the outside, meaning: responseClass
> is
> > null or Response, and exchange is out capable.
> >
> >
> >
> >
> > --
> > View this message in context: http://camel.465427.n5.nabble.
> com/CxfRs-producer-connection-not-closed-tp5759664p5759711.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
>
Re: CxfRs producer: connection not closed
Posted by Willem Jiang <wi...@gmail.com>.
I think CXF WebClient already take care of it, the response is input stream, the user should close it himself.
In camel-http, the http client auto close the connection when it out of scope, so we have to copy the stream in camel for the outside usage. But it’s the user responsibility to close the stream after consuming the stream.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On November 27, 2014 at 10:00:16 PM, thib (thibaut.robert@gmail.com) wrote:
> Thanks, I looked at your fix, seems prefectly fine for my usage. I have one
> question however:
> Should'nt you close the connection also when responseClass is provided ?
> (whatever the exchange pattern)
>
> I would think that response/connection should be left open only when we are
> able to consume (and close) it from the outside, meaning: responseClass is
> null or Response, and exchange is out capable.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CxfRs-producer-connection-not-closed-tp5759664p5759711.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: CxfRs producer: connection not closed
Posted by thib <th...@gmail.com>.
Thanks, I looked at your fix, seems prefectly fine for my usage. I have one
question however:
Should'nt you close the connection also when responseClass is provided ?
(whatever the exchange pattern)
I would think that response/connection should be left open only when we are
able to consume (and close) it from the outside, meaning: responseClass is
null or Response, and exchange is out capable.
--
View this message in context: http://camel.465427.n5.nabble.com/CxfRs-producer-connection-not-closed-tp5759664p5759711.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CxfRs producer: connection not closed
Posted by Willem Jiang <wi...@gmail.com>.
Thanks for pointing that out, I just created a JIRA[1] for it.
[1]https://issues.apache.org/jira/browse/CAMEL-8082
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On November 27, 2014 at 1:26:44 AM, Thibaut Robert (thibaut.robert@gmail.com) wrote:
> Hi,
>
> When using cxfRs to send a rest message in InOnly mode, Camel do not close
> the javax.ws.rs.core.Response object. As we are InOnly, the reponse object
> is not passed through the exchange, so the caller can not close it either.
>
> Not calling close on the response maintain the input stream open (and the
> associated tcp connection) until it times out (or gc'ed), which is not
> desirable.
>
> As a workaround I always use InOut mode and close the response, even if I'm
> not interested in the result.
>
> Example (scala code):
>
> val camel = new DefaultCamelContext().createProducerTemplate()
> val destination = "http://localhost:1234"
> val body = """{"key":"value"}"""
> // Leave an open connection
> //camel.sendBody("cxfrs:" + destination, body)
> // use instead:
> camel.requestBody("cxfrs:" + destination,
> body).asInstanceOf[Response].close()
>
>
> Is it possible to change this behaviour in Camel ?
>
> Thanks
>
> --
> Thibaut
>