You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "aaron pieper (JIRA)" <ji...@apache.org> on 2010/01/15 20:24:54 UTC
[jira] Created: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
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.5, 2.2.4, 2.2.3, 2.2.6
Environment: Windows XP
Reporter: aaron pieper
Priority: Minor
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.
[jira] Commented: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
Posted by "aaron pieper (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800881#action_12800881 ]
aaron pieper commented on CXF-2619:
-----------------------------------
Hmm okay that sounds like a good change, I can see how that would improve performance for most use cases. This is kind of a peculiar edge case, this kind of a servlet isn't very practical in production - we merely use it for our unit tests to make sure we handle incoming/outgoing attachments properly.
Both of your suggested solutions seem OK (a configuration step, or detecting the first write) - although it seems like no matter what, you'd want to detect the potential for deadlock, and either prebuffer the attachment or just throw some kind of a human-readable error with some text describing the issue.
> 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.
[jira] Assigned: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp reassigned CXF-2619:
--------------------------------
Assignee: Daniel Kulp
> 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
> Assignee: Daniel Kulp
> 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.
[jira] Commented: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800872#action_12800872 ]
Daniel Kulp commented on CXF-2619:
----------------------------------
Another option MIGHT be to detect the first write to the output stream on the server side and have that trigger a buffering of everything on the incoming side. Something for me to ponder...............
> 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.
[jira] Resolved: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-2619.
------------------------------
Resolution: Fixed
Fix Version/s: 2.2.6
2.1.9
> 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
> Assignee: Daniel Kulp
> Priority: Minor
> Fix For: 2.1.9, 2.2.6
>
> 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.
[jira] Updated: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
Posted by "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.
[jira] Commented: (CXF-2619) Deadlock when echoing MTOM attachments
back to client
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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.