[jira] [Comment Edited] (CXF-6863) WS-RM 3.x does not work with attachments upon a network error

["Dennis Sosnoski (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319452#comment-15319452 ] 

Dennis Sosnoski edited comment on CXF-6863 at 6/7/16 9:19 PM:
--------------------------------------------------------------

That sounds completely correct, Aki. Sorry for my misunderstanding of what was being done, and glad to see you're cleaning up the remaining glitches in this messy code.

The only other issue I can think of is that if you're combining all attachments into a single blob, won't this interfere with security for attachments? It's been a while since I looked at this, but I thought you could configure separate WS-Security for individual attachments.


was (Author: dsosnoski):
That sounds completely correct, Aki. Sorry for my misunderstanding of what was being done, and glad to see you're cleaning up the remaining glitches in this messy code.

> WS-RM 3.x does not work with attachments upon a network error
> -------------------------------------------------------------
>
>                 Key: CXF-6863
>                 URL: https://issues.apache.org/jira/browse/CXF-6863
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>    Affects Versions: 3.1.3, 3.0.9
>            Reporter: Akitoshi Yoshida
>            Assignee: Akitoshi Yoshida
>         Attachments: 0001-WS-RM-3.x-fix-for-retransmission-works-with-attachme.patch
>
>
> When sending messages with an attachment, the CXF 3.x WS-RM code may lose message at the client side when a network error occurs. This was working with CXF 2.x WS-RM.
> This problem is related to the change CXF-4866 which changed the way how the outgoing message is captured. Previously, the entire message was buffered and captured, which isolated this capturing from network issue. In 3.x, only the SOAP part is captured in this way and not the attachments. As a result, an exception will be thrown during the attachment serialization when a network error occurs and the message will not be correctly placed in the retransmission queue.
> By comparing CXF 3.x and 2.x code, 
> In 3.x., AttachmentSerializer.writeProlog will directly writes to the IO and this can trigger a Fault from AttachmentOutInterceptor.handleMessage.
> URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractThresholdOutputStream).write(byte[], int, int) line: 61	
> URLConnectionHTTPConduit$URLConnectionWrappedOutputStream(AbstractWrappedOutputStream).write(byte[]) line: 60	
> CacheAndWriteOutputStream.write(byte[]) line: 89	
> AttachmentSerializer.writeProlog() line: 182	
> AttachmentOutInterceptor.handleMessage(Message) line: 77	
> whereas in CXF 2.x, AttachmentSerializer.writeProlog will write to the buffered WriteOnCloseOutputStream, as its RetransmissionInterceptor inserts WriteOnCloseOutputStream to isolate itself from any network issue.
> WriteOnCloseOutputStream(CachedOutputStream).write(byte[]) line: 466	
> CacheAndWriteOutputStream.write(byte[]) line: 89	
> AttachmentSerializer.writeProlog() line: 172	
> AttachmentOutInterceptor.handleMessage(Message) line: 72	
> CXF 2.x, RetransmissionInterceptor inserted WriteOnCloseOutputStream to capture the message entirely.
> There seem to be other issues with attachments handling in CXF 3.x. Along with other issues CXF-6646, I am not sure how we should fix all these issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)