[
https://issues.apache.org/jira/browse/XMLRPC-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707795#action_12707795
]
Alan Burlison edited comment on XMLRPC-167 at 5/10/09 7:57 AM:
---------------------------------------------------------------
I *knew* I'd written my transport factory to return a singleton transport for a
reason, this is from XmlRpcTransportFactory:
----------
/** Returns an instance of {...@link XmlRpcTransport}. This may
* be a singleton, but the caller should not depend on that:
* A new instance may as well be created for any request.
* @return The configured transport.
*/
public XmlRpcTransport getTransport();
----------
Jochen. that contradicts your statement that "the transport was never meant to
be thread safe and will never be thread safe". There is no way a transport
factory can return an unsynchronized singleton and still be thread-safe.
I can either add the synchronization or fix the comment, but one or the other
needs to be done. Which would you prefer?
was (Author: alanbur):
I *knew* I'd written my transport factor to return a singleton transport
for a reason, this is from XmlRpcTransportFactory:
----------
/** Returns an instance of {...@link XmlRpcTransport}. This may
* be a singleton, but the caller should not depend on that:
* A new instance may as well be created for any request.
* @return The configured transport.
*/
public XmlRpcTransport getTransport();
----------
Jochen. that contradicts your statement that "the transport was never meant to
be thread safe and will never be thread safe". There is no way a transport
factory can return an unsynchronized singleton and still be thread-safe.
I can either add the synchronization or fix the comment, but one or the other
needs to be done. Which would you prefer?
> 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.
