[
https://issues.apache.org/jira/browse/XMLRPC-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706017#action_12706017
]
Alan Burlison commented on XMLRPC-167:
--------------------------------------
I've wrapped the InputStream read by XmpRpcStreamTransport with a simple class
that just prints out the thread ID and the method to a passed output stream
before passing the calls through to the wrapped class:
InputSource isource = new InputSource(pStream);
becomes:
InputSource isource = new InputSource(new InputStreamTracer(pStream,
System.out, Thread.currentThread().getName()));
When I run my test client with two threads I get the following trace, which
clearly shows that two threads are both trying to read the same reply from the
server at the same time, hence the breakage.
Thread-0: read() = "<"
Thread-1: read() = "?"
Thread-0: read() = "x"
Thread-1: read() = "m"
Thread-0: read() = "l"
Thread-1: read() = " "
Thread-1: read() = "e"
Thread-0: read() = "v"
Thread-0: read(buff, 0, 28) = 28 "?><methodResponse><fault><va"
Thread-1: read(buff, 0, 28) = 28 "rsion="1.0" encoding="UTF-8""
[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.
There's clearly a race condition here, and clearly a missing lock around the
input stream.
> 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.
