Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.1.2
-
None
-
None
-
Solaris
Description
http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/client/XmlRpcClient.html says:
----------
A configured XmlRpcClient object is thread safe: In other words, the suggested use is, that you configure the client using setTransportFactory(XmlRpcTransportFactory) and similar methods, store it in a field and never modify it again. Without modifications, the client may be used for an arbitrary number of concurrent requests.
----------
I have a simple test case that creates two threads that share a single XmlRpcClient instance, and if I run the test I see the following errors:
----------
Fatal Error] :1:1: Content is not allowed in prolog.
operation failed, Failed to parse server's response: Content is not allowed in prolog.
[Fatal Error] :1:10: Element type "xlvrsion" must be followed by either attribute specifications, ">" or "/>".
operation failed, Failed to parse server's response: Element type "xlvrsion" must be followed by either attribute specifications, ">" or "/>".
----------
----------
[Fatal Error] :1:1: Content is not allowed in prolog.
[Fatal Error] :1:5: Element type "xlv" must be followed by either attribute specifications, ">" or "/>".
operation failed, Failed to parse server's response: Element type "xlv" must be followed by either attribute specifications, ">" or "/>".
operation failed, Failed to parse server's response: Content is not allowed in prolog.
----------
If I wrap the call to XmlRpcClient.execute with a synchronized block that locks on the XmlRpcClient object, the code works fine.
It looks like the execute code is not locking around the read/write to/from the server, so the threads are competing to read the response from the server, and are tripping over each other.
Attachments
Issue Links
- is related to
-
XMLRPC-168 XML-RPC server deadlocks under heavy load
- Resolved