[jira] Updated: (CXF-2619) Deadlock when echoing MTOM attachments back to client

["aaron pieper (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

aaron pieper updated CXF-2619:
------------------------------

    Attachment: frt.zip

A maven module demonstrating the issue. This uses CXF v2.2.3, and relies on several aspects of CXF. It generates Java stubs using CXF, and uses the CXF jetty transport for its test case.

I see the following results after executing an mvn clean install:

Running frt.impl.LargeFileTest
Tests run: 8, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 32.062 sec <<< FAILURE!

Results :

Tests in error:
  testCanHandle100KilobyteMtomUpload(frt.impl.LargeFileTest)
  testCanHandle500KilobyteMtomUpload(frt.impl.LargeFileTest)

Tests run: 8, Failures: 0, Errors: 2, Skipped: 0

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