XML-RPC
  1. XML-RPC
  2. XMLRPC-167

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

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2
    • Fix Version/s: None
    • Component/s: Source
    • Labels:
      None
    • Environment:
      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.

        Issue Links

          Activity

          Alan Burlison created issue -
          Alan Burlison made changes -
          Field Original Value New Value
          Link This issue is related to XMLRPC-168 [ XMLRPC-168 ]
          Alan Burlison made changes -
          Attachment XMLRPC-167.patch [ 12407381 ]
          Alan Burlison made changes -
          Attachment XMLRPC-167.patch [ 12407381 ]
          Mark Thomas made changes -
          Workflow jira [ 12461990 ] Default workflow, editable Closed status [ 12565449 ]
          Mark Thomas made changes -
          Workflow Default workflow, editable Closed status [ 12565449 ] jira [ 12599043 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Alan Burlison
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development