[
https://issues.apache.org/jira/browse/XMLRPC-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707176#action_12707176
]
Alan Burlison commented on XMLRPC-167:
--------------------------------------
I'll check out the 1.4/1.5 issue, I thought I was seeing my code go through the
1.5 variant when I was stepping through it in the debugger, but I'll double
check.
The issue is that the object returned by getTransport() isn't thread-safe, so
if you share that returned object between two threads they can both end up
using the same underlying URLconnection at the same time, and that's what
causes the problem. You can get into that situation in turn if you share the
XmlRpcClient object that doles out the transports between two threads.
It may be the case that I'm setting up the XML-RPC 'stack' incorrectly in the
first place, but the docs do say that XmlRpcClient is thread-safe. The code
that implements my client can be found at
http://src.opensolaris.org/source/xref/website/auth/AuthClient/src/org/opensolaris/auth/client/AuthClient.java,
it may be worth you taking a look at that to make sure I'm not violating some
assumption that the XML-RPC library makes about how things are set up - it's
entirely possible I am :-)
As for my 'real' app, it is doing more realistic processing in both the client
& the server (crypto stuff), so the window for the race condition to occur is
wider and therefore easier to hit.
> 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
> Attachments: XMLRPC-167.patch
>
>
> 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.
