[
https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037724#comment-13037724
]
ext2 commented on CXF-3504:
---------------------------
@FreeMan Fang:
by the way, I suggest you'd better to add the checking code of Delegate input
stream's close to avoid recursively close one delegate-input-stream twice;
Tne delegate-input-stream will be recursived closed twice; to ensure this, you
can tracking it use a java-debugger: the calling stack is :
DelegateInputStream.close-->deserailizer.markClosed()-->attachmentDeserailizer.hasNext()-->attachment.cache()-->DelegateInputStream.close()
[here recursive occurs]
Anyway, if we don't check it, thinks will also work right.(because
delegate-input-stream is only used by the last attachment). but it may cause
potential problem in future;
> for big attachment, a temporary file is left on disk and keep opend, if the
> application just close the DataSource's inputStream and doesn't consume it;
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-3504
> URL: https://issues.apache.org/jira/browse/CXF-3504
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.4
> Reporter: ext2
> Assignee: Freeman Fang
> Fix For: 2.4.1, 2.3.5
>
> Attachments: CXF-3504-new.patch, CXF-3504.patch,
> attachment-clean.zip, mtom.wsdl
>
>
> when the client receiving multiple larget attachments from server. here
> "large" means : attachment size is large enough to be saved as temporary file
> on disk;
> for the last attachment, if the user application only close the input stream
> got from DataSource and doesn't consume the input stream at all, a temporary
> file will be left on the disk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
