[
https://issues.apache.org/jira/browse/CXF-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800870#action_12800870
]
Daniel Kulp commented on CXF-2619:
----------------------------------
This is really "working as designed". Prior to 2.2.3, attachments were all
buffered (onto disk for >64K, memory otherwise) when read in.
No real "steaming" was done on the incoming side. Thus, by the time the
method on your server impl was invoked, the client was done sending things and
had started attempting to read from the input stream.
With 2.2.3, we introduced pure streaming of incoming attachments which is what
is ideal for MOST use cases as it gets into the real logic earlier and performs
much better as nothing is buffered anywhere. However, that runs into a problem
in your usecase. Basically, in your case, the client is still trying to
write the attachment to it's OutputStream. It hasn't yet started trying to
read from the InputStream. However, your server has started writing. The
outgoing buffers fill and it deadlocks waiting for the client to read.
We COULD add a configuration parameter to turn off the incoming streaming,
although you would achieve the same result by buffering it yourself as you
mentioned.
Another option is to just configure in the SAAJInInterceptor or
schema-validation. I believe both of them require the attachments to be
pulled in and buffered as well.
> Deadlock when echoing MTOM attachments back to client
> -----------------------------------------------------
>
> Key: CXF-2619
> URL: https://issues.apache.org/jira/browse/CXF-2619
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.3, 2.2.4, 2.2.5, 2.2.6
> Environment: Windows XP
> Reporter: aaron pieper
> Priority: Minor
> Attachments: frt.zip
>
>
> I've written a simple "echo" web service, which receives an attachment and
> echoes it back. In CXF 2.2.2 and earlier, this works OK. Starting with CXF
> 2.2.3, however, there is a somewhat unpredictable deadlock situation which
> occurs with MTOM attachments, which causes the web server to deadlock, so
> that it never responds to the request.
> This situation often occurs when the attachment is around 85 kilobytes or
> greater in size. However, this boundary is not 100% consistent. Sometimes I
> can successfully echo attachments up to 88 kilobytes in size, and sometimes
> smaller attachments trigger the bug.
> The behavior only occurs if the same input stream is reused. Copying the
> input into a new input stream circumvents the error. I've verified this
> behavior began with CXF 2.2.3, and is still present in the latest
> 2.2.6-SNAPSHOT.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
