You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Martin Renner (JIRA)" <ji...@apache.org> on 2010/08/13 10:28:16 UTC

[jira] Created: (CXF-2940) AttachmentOutInterceptor does not always close the input streams

AttachmentOutInterceptor does not always close the input streams
----------------------------------------------------------------

                 Key: CXF-2940
                 URL: https://issues.apache.org/jira/browse/CXF-2940
             Project: CXF
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.0.13, 2.1.10, 2.2.9, 2.2.8, 2.2.7, 2.2.6, 2.1.9, 2.2.5, 2.1.8, 2.2.4, 2.1.7, 2.2.3, 2.1.6, 2.0.12, 2.2.2, 2.2.1, 2.1.5, 2.2, 2.1.4, 2.1.3, 2.1.2, 2.1.1, 2.1
            Reporter: Martin Renner


Under some circumstances, AttachmentOutInterceptor does not close the input stream that it uses to read the contents of an attachment and to stream it to the client. This can lead to a resource leak, because those input streams often belong to server resources like database results, files from the server's filesystem etc.

The stream gets closed, if an exception occurs _while_ streaming the content of one particular input stream to the client. However, the streams are not closed, if
* an exception occurs on the outbound chain somewhere between the very first interceptor and AttachmentOutInterceptor.
* there are several attachments, writing of one fails (maybe because the client closed the connection) and there are some more attachments left. Then the streams of those outstanding attachments won't get closed.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-2940) AttachmentOutInterceptor does not always close the input streams

Posted by "Martin Renner (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898131#action_12898131 ] 

Martin Renner commented on CXF-2940:
------------------------------------

I will provide a patch for this problem. See also this thread on the [Mailing list|http://mail-archives.apache.org/mod_mbox/cxf-users/201008.mbox/%3Cd68cb800ae2dd838ddb4beab4ee58e229a2891de@localhost%3E].

> AttachmentOutInterceptor does not always close the input streams
> ----------------------------------------------------------------
>
>                 Key: CXF-2940
>                 URL: https://issues.apache.org/jira/browse/CXF-2940
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, 2.1.5, 2.2.1, 2.2.2, 2.0.12, 2.1.6, 2.2.3, 2.1.7, 2.2.4, 2.1.8, 2.2.5, 2.1.9, 2.2.6, 2.2.7, 2.2.8, 2.2.9, 2.1.10, 2.0.13
>            Reporter: Martin Renner
>
> Under some circumstances, AttachmentOutInterceptor does not close the input stream that it uses to read the contents of an attachment and to stream it to the client. This can lead to a resource leak, because those input streams often belong to server resources like database results, files from the server's filesystem etc.
> The stream gets closed, if an exception occurs _while_ streaming the content of one particular input stream to the client. However, the streams are not closed, if
> * an exception occurs on the outbound chain somewhere between the very first interceptor and AttachmentOutInterceptor.
> * there are several attachments, writing of one fails (maybe because the client closed the connection) and there are some more attachments left. Then the streams of those outstanding attachments won't get closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (CXF-2940) AttachmentOutInterceptor does not always close the input streams

Posted by "Martin Renner (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Renner closed CXF-2940.
------------------------------

    Resolution: Invalid

Andreas, you are right. The API doc of DataSource clearly mentions, that a new InputStream has to be created for every call to {{getInputStream}}.

I am closing this issue as _Invalid_.

> AttachmentOutInterceptor does not always close the input streams
> ----------------------------------------------------------------
>
>                 Key: CXF-2940
>                 URL: https://issues.apache.org/jira/browse/CXF-2940
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, 2.1.5, 2.2.1, 2.2.2, 2.0.12, 2.1.6, 2.2.3, 2.1.7, 2.2.4, 2.1.8, 2.2.5, 2.1.9, 2.2.6, 2.2.7, 2.2.8, 2.2.9, 2.1.10, 2.0.13
>            Reporter: Martin Renner
>
> Under some circumstances, AttachmentOutInterceptor does not close the input stream that it uses to read the contents of an attachment and to stream it to the client. This can lead to a resource leak, because those input streams often belong to server resources like database results, files from the server's filesystem etc.
> The stream gets closed, if an exception occurs _while_ streaming the content of one particular input stream to the client. However, the streams are not closed, if
> * an exception occurs on the outbound chain somewhere between the very first interceptor and AttachmentOutInterceptor.
> * there are several attachments, writing of one fails (maybe because the client closed the connection) and there are some more attachments left. Then the streams of those outstanding attachments won't get closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-2940) AttachmentOutInterceptor does not always close the input streams

Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898185#action_12898185 ] 

Andreas Veithen commented on CXF-2940:
--------------------------------------

Martin,

Your analysis is based on a wrong assumption, namely that DataSource is a holder for an already open InputStream. This is not true. The InputStream is only created when the getInputStream method is called, and for every invocation, a new InputStream is created (i.e. DataSource acts as a factory for InputStream objects). Therefore, InputStream#close() must be called once for every call to DataSource#getInputStream. In particular, if DataSource#getInputStream is never called, the code consuming the DataSource doesn't need to do any cleanup. Note that this is clearly specified in the Javadoc of the DataSource interface. Thus, the resource leak only occurs if the DataSource implementation doesn't conform to the contract of the DataSource interface.

> AttachmentOutInterceptor does not always close the input streams
> ----------------------------------------------------------------
>
>                 Key: CXF-2940
>                 URL: https://issues.apache.org/jira/browse/CXF-2940
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, 2.1.5, 2.2.1, 2.2.2, 2.0.12, 2.1.6, 2.2.3, 2.1.7, 2.2.4, 2.1.8, 2.2.5, 2.1.9, 2.2.6, 2.2.7, 2.2.8, 2.2.9, 2.1.10, 2.0.13
>            Reporter: Martin Renner
>
> Under some circumstances, AttachmentOutInterceptor does not close the input stream that it uses to read the contents of an attachment and to stream it to the client. This can lead to a resource leak, because those input streams often belong to server resources like database results, files from the server's filesystem etc.
> The stream gets closed, if an exception occurs _while_ streaming the content of one particular input stream to the client. However, the streams are not closed, if
> * an exception occurs on the outbound chain somewhere between the very first interceptor and AttachmentOutInterceptor.
> * there are several attachments, writing of one fails (maybe because the client closed the connection) and there are some more attachments left. Then the streams of those outstanding attachments won't get closed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.