You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "ext2 (JIRA)" <ji...@apache.org> on 2011/05/10 05:52:03 UTC
[jira] [Created] (CXF-3504) 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;
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
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
[jira] [Resolved] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang resolved CXF-3504.
-------------------------------
Resolution: Fixed
Fix Version/s: 2.3.5
2.4.1
commit fix
http://svn.apache.org/viewvc?rev=1104243&view=rev for trunk
http://svn.apache.org/viewvc?rev=1104252&view=rev for 2.3.x branch
> 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: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CXF-3504) 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;
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036656#comment-13036656 ]
Willem Jiang commented on CXF-3504:
-----------------------------------
@ext2
There is not much change of the attachement code between CXF 2.3.x and CXF 2.4.x.
Can you submit your patch with the test case? We are happy to accept the contribution :)
> 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: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036126#comment-13036126 ]
ext2 commented on CXF-3504:
---------------------------
Yes the patch will leave no temporary file on disk.
But it introduce another problem: the http-connection doesn't closed;
After execute the last-attachment input-stream's close, I can saw a "ESBTABLISHING" status socket, that indicate the socket cannot be closed;
To understand the problem, let's check some source code of CXF attachment:
class AttachmentDeserializer{
//because the patch just close MIMEPartInputStream, so the network-inputstream isn't consumed over; then stream.read() will return another bytes to indicate the "we still have another attachment"(but actually , we didn't)
public boolean hasNext() throws IOException {
.......
int v = stream.read();
if (v == -1) {
return false;
}
stream.unread(v);
return true;
}
//now because attachments.hasNext() will never return false, so the network-stream cannot be closed;
public void markClosed(DelegatingInputStream delegatingInputStream){
closedCount++;
if (closedCount == createCount && !attachments.hasNext(false)) {
int x = stream.read();
while (x != -1) {
x = stream.read();
}
stream.close();
closed = true;
}
}
}
> 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: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037722#comment-13037722 ]
ext2 commented on CXF-3504:
---------------------------
@FreeMan Fang
I have tried the new patch. it could works in my scenior;
Thanks a lot;
> 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
[jira] [Updated] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated CXF-3504:
------------------------------
Attachment: CXF-3504.patch
> 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.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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036634#comment-13036634 ]
ext2 commented on CXF-3504:
---------------------------
I am sure I have correct patch for CXF3504 and CXF3505. there are still socket left not closed;
Actualy the new problem (http-connection not close ) caused by CXF 3504 's patch is different to the CXF3505.
cxf3505's bug are always: server socket closed, client not closed(FIN_WAIT socket STATUS);
the new problem of CXF 3504 's patch are : server and client both not closed[ESTABLISHED SOCKET STATUS] if you provide a LARGE ENOUGH attachment, you will find
HERE :LARGE ENOUGH ATTACHMENT means :attatchment’size should be larger than double size of underly buffer for socket), In my enviroment I using a 64K attachment in JDK5 and windows XP system。 the attachment size is quite different on different operation-system and JDK.
You can try it by using a very big attachment[etc: 10M size (arbitrary)]
> 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: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036781#comment-13036781 ]
ext2 commented on CXF-3504:
---------------------------
@FreeMan Fang:
My private temporary fix is quite different;the strategy I am using is: "doesn't make attachments pre cached" but "make delegate input stream always work right"; That's to say if using sun's activation. my private fix will still keep all attachment being delegate inputstream(doesn't cach any one);
key fixed as following :
1)avoid recursive calling to DelegateInputStream's close
boolean closing = false;
DelegateInputStream.close{
if(!closing){
closing = true;
is.close();
if (!isClosed && deserializer != null) {
deserializer.markClosed(this);
}
isClosed = true;
}
}
2) consume all underlying bytes while close MIMEPartInputStream()-->(avoid mis read MIME part: for example, if user just close first attachment, and doesn't read it, then read second attachment)
MIMEPartInputStream.close(){
while(read() >= 0)
;
}
now using sun's activation will be better than geronimo; because the attachment's content will never be cached if user doesnt' care about content of the attachment
> 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
[jira] [Updated] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated CXF-3504:
------------------------------
Attachment: CXF-3504-new.patch
> 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
[jira] [Commented] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034767#comment-13034767 ]
Freeman Fang commented on CXF-3504:
-----------------------------------
This is caused by still can read MimeBodyPartInputStream after closing it, so that after closing the unread stream , it cache to temp file but have no chance to delete temp file even the process exit.
> 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
> Attachments: 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
[jira] [Updated] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ext2 updated CXF-3504:
----------------------
Attachment: mtom.wsdl
> 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
> Attachments: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036128#comment-13036128 ]
ext2 commented on CXF-3504:
---------------------------
maybe while close the MIMEPartInputstream, the close method should consume all content of Current MIMEPart from underly input stream;
> 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: 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
[jira] [Assigned] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang reassigned CXF-3504:
---------------------------------
Assignee: Freeman Fang
> 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
> Attachments: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036148#comment-13036148 ]
Freeman Fang commented on CXF-3504:
-----------------------------------
Hi,
Actually after closing MIMEPartInputStream, when you try to read this stream, it will always -1, that's exactly this fix does, you can get more details from[1].
And when you observe http-connection doesn't closed, did you already include my fix from CXF-3505? I believe CXF-3505 fix the http-connection issue.
[1]http://svn.apache.org/viewvc/cxf/trunk/rt/core/src/main/java/org/apache/cxf/attachment/MimeBodyPartInputStream.java?r1=1104243&r2=1104242&pathrev=1104243
Freeman
> 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: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036780#comment-13036780 ]
Freeman Fang commented on CXF-3504:
-----------------------------------
Or simply read through DelegatingInputStream when you close it, ensure no cache file left on disk and correctly close the connection.
Append as CXF-3504-new.patch
> 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
[jira] [Commented] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037823#comment-13037823 ]
Freeman Fang commented on CXF-3504:
-----------------------------------
Hi,
I think the recursive call is ok here.
First of all, not all ins in attachment.cache is DelegateInputStream, and we need close the ins in anycase after caching it.
If the ins in attachment.cache is DelegateInputStream, it's also fine, the deserializer.markClosed(this) can safely end the call and won't cause infinite invocation.
I'll commit my new patch soon.
Freeman
> 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
[jira] [Updated] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ext2 updated CXF-3504:
----------------------
Attachment: attachment-clean.zip
this is the test case's pom project.
> 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
> Attachments: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "ext2 (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036639#comment-13036639 ]
ext2 commented on CXF-3504:
---------------------------
when I reported CXF3504 & CXF3505 bug previously, I just use a "user's word to say what the problem I have saw outside CXF". But the underly technical reason which caused CXF3505 & CXF3504 are differnet;
CXF3505 's underly reason is: sun's activation library caused all attachments are delegate to inputstream ( not cached) ;the patch for CXF3505 only fixed: only last attachment using delegate inputstream, other attachments cached. Anyway there is still a attachment(the last) which using delegate inputstream;
CXF3504's underly reason is : delegate input stream 's close method doest take care of underly-http-connection and Cacheing mechanism both; the original code of CXF only tare of underly-http-connection 's close; and the new patch of CXF3504 only take care of Cacheing mechanism.
By the way， I fixed the patch of CXF3504 and CXF3505 in CXF2.3.3 version. (although I think the trunk source code of CXF2.4 also have the new problem, but I haven't tried it yet)
> 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: 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
[jira] [Commented] (CXF-3504) 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;
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036722#comment-13036722 ]
Freeman Fang commented on CXF-3504:
-----------------------------------
Hi,
Ok, I saw the introduced connection can't release issue, it also only happened when you not actually read the attachment stream but close it directly.
The fix should be when we close a stream, we needn't check if there's hasNext attachment(as we intend to close it, we don't care if there's any attachment we don't read), just mark this stream as closed.
I will append a new patch, could you verify it works for your scenario?
Also, if you wanna contribute your patch you mentioned before, I'm very glad to review it.
Freeman
> 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.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