You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Jens Riemschneider (JIRA)" <ji...@apache.org> on 2009/08/05 16:07:14 UTC

[jira] Commented: (CXF-2381) Attachments gone when in Multi-Threaded client

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

Jens Riemschneider commented on CXF-2381:
-----------------------------------------

I should add that I have reproduced this problem with CXF 2.1.4, 2.1.6 and 2.2.2.

> Attachments gone when in Multi-Threaded client
> ----------------------------------------------
>
>                 Key: CXF-2381
>                 URL: https://issues.apache.org/jira/browse/CXF-2381
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>            Reporter: Jens Riemschneider
>
> Multi-Threaded client using a web-services that returns one or multiple attachments (MTOM). Client stubs are not shared between threads. HTTP-Binding and WS-Addressing is used.
> From time to time attachments are missing is the response. After playing around with this for some time I found that data that is read from the PushbackInputStream often gets unread shortly afterwards. When the problem occurred this did not happen, causing the AttachmentDeserializer to "think" that there are fewer attachments. After more digging, I found this member in HTTPConduit:
>     private static final byte BUFFER[] = new byte[1024];
> This is only used in the HTTPConduit.close(). However, it is shared between all instances of HTTPConduit and it seems to be possible that close() gets called by multiple threads. Ensuring that the buffer is created within close() seems to solve the problem, however, there are most likely better solutions to this.

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