[CXF-5078] WSDLGetInterceptor holds a lock for too long

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.5.10, 2.6.8, 2.7.5
• Fix Version/s: 2.5.11, 2.6.9, 2.7.6
• Component/s: Simple Frontend
• Labels: patch
• Estimated Complexity: Unknown
• Assignee: Daniel Kulp
• Reporter: John Bellassai
• Created: 13/Jun/13 20:50
• Updated: 14/Aug/13 15:49
• Resolved: 17/Jun/13 18:54

Description

WSDLGetInterceptor both creates the WSDL Document object and writes that data to the OutputStream while holding onto a lock. This can cause major issues in an environment where that data is being sent to very slow clients or there are other general networking issues.

We have seen this problem manifest multiple times in a production environment where all of Tomcat's connection handler threads pile up while waiting for this lock to become available because it is being held by a thread which is trying to write to a socket but cannot for whatever reason. Eventually Tomcat stops responding to new requests and must be bounced.

Daniel Kulp suggested that instead of writing the WSDL Document directly to the OutputStream from the message, rather write it to a CachedOutputStream while holding the lock. Then outside of the synchronized block, copy it from the CachedOutputStream to the real OutputStream to the client. In this way, a single bad connection or slow client cannot cause trouble for others.

I will attach a patch made against the lastest WSDLGetInterceptor from 2.7.6-SNAPSHOT.

Issue Links

• is related to: CXF-5151 WSDLGetInterceptor supports GZIP encoding