cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Commented: (CXF-2619) Deadlock when echoing MTOM attachments back to client
Date Fri, 15 Jan 2010 19:40:54 GMT


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:
>             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:
> 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.

View raw message