XmlRpcClient is supposed to be thread-safe but it isn't
-------------------------------------------------------
Key: XMLRPC-167
URL: https://issues.apache.org/jira/browse/XMLRPC-167
Project: XML-RPC
Issue Type: Bug
Components: Source
Affects Versions: 3.1.2
Environment: Solaris
Reporter: Alan Burlison
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
