Uploaded image for project: 'XML-RPC'
  1. XML-RPC
  2. XMLRPC-167

XmlRpcClient is supposed to be thread-safe but it isn't

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 3.1.2
    • None
    • Source
    • 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

          Activity

            People

              Unassigned Unassigned
              alanbur Alan Burlison
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated: