Hi Sergey, thank you for your quick reply! :) I have read the source code of the class LoadedByteArrayInputStream and TransferableFileInputStream. Calling the "IOUtils.transferTo" method on a instance of LoadedByteArrayInputStream creates a new file from the bytes in memory. Instead calling that method on a TransferableFileInputStream try to rename the file to another one and if the rename fails it does a new copy of the file. I also suspect that if the file is renamed the old temp referenced in org.apache.cxf.io.CachedOutputStream not exists anymore and this may cause a (not blocking) error trying to delete it in the method "deleteTempFile()" that is called when we close the stream.
I would like to avoid an unnecessary copy/rename to a new file (e.g. for byte array) and would like to find an alternative if possibile to let my code to reopen the stream on the temporary file an arbitrary number of times. Do you think that an interceptor calling: org.apache.cxf.io.CachedOutputStream.holdTempFile() on all attachments before processing (what phase?) the request in our backend class and another interceptor after the response has been processed may work? For an example see a suggestion from Dan in the last post of a my old post: http://cxf.547215.n5.nabble.com/Temporary-files-created-for-data-over-64kb-are-never-deleted-swaref-td5738911.html "That definitely could would work. At the VERY VERY end of the in chain, you could possibly grab the attachment list out of the message and just loop through and close each one." Thank you very much. Stefano. -- View this message in context: http://cxf.547215.n5.nabble.com/Empty-stream-when-reading-twice-the-content-of-an-attachment-greater-than-100KB-tp5745031p5745052.html Sent from the cxf-user mailing list archive at Nabble.com.
