From daniel at sentivision.com Fri Apr 18 08:37:26 2008 From: daniel at sentivision.com (Daniel Janus) Date: Fri, 18 Apr 2008 10:37:26 +0200 Subject: [s-xml-rpc-devel] [PATCH] Interoperability issue with WS-XMLRPC Message-ID: <1208507846.15261.18.camel@daniel> Hello, I'm using the current asdf-installable version of S-XML-RPC with SBCL 1.0.15 (hand-compiled from source on an i686) and have been trying to connect with its client API to various XML-RPC servers. It has been mostly working, with only an exception of one server. The server in question is an enterprise Java EE 5 application, written using Apache WS-XMLRPC library (version 3.1 to be more precise) and deployed on a cluster consisting of two Glassfish enterprise server instances, both running on Ubuntu 6.06.1. The problem manifests itself in XML-RPC-CALL -- it bails out with an error "no response from server". I tried another XML-RPC stack (the one that comes with Python) and I had no problems with making the same request to the same server. I did some preliminary investigation and found a workaround to the problem. It seems that building up the whole XML-RPC request beforehand, then sending it all at once (rather than FORMATting the HTTP headers to the TCP stream one-by-one) fixes the problem. This is what the attached patch does. I enclose it just in case someone else runs into the same problem; it works for me, on the downside, it probably causes the library to do more consing, although I did not check that empirically. Strangely enough, the problem does not seem to occur with an installation of the very same Java application on a single (non-clustered) Glassfish running on newer versions of Ubuntu. Clearly, more detailed investigation is required. As soon as I have time for that, I will attempt to reproduce the behaviour on various setups and using various Lisps (I have access to Allegro 8.1), to see where the problem really lies. I hope for attaining a true fix instead of a workaround. I will send a followup as soon as I have more detailed information. Best, -- Daniel Janus Senior Software Engineer, SENTIVISION Mb: +48.501180396 | Ph: +48.226400860 -------------- next part -------------- A non-text attachment was scrubbed... Name: ws.patch Type: text/x-patch Size: 1681 bytes Desc: not available URL: From rudi at constantly.at Fri Apr 18 09:24:11 2008 From: rudi at constantly.at (Rudi Schlatte) Date: Fri, 18 Apr 2008 11:24:11 +0200 Subject: [s-xml-rpc-devel] [PATCH] Interoperability issue with WS-XMLRPC In-Reply-To: <1208507846.15261.18.camel@daniel> References: <1208507846.15261.18.camel@daniel> Message-ID: <4D11865F-1EB4-4C6D-A06A-174A97B91CEC@constantly.at> I don't have any answers, just some observation and speculation. On 18.04.2008, at 10:37, Daniel Janus wrote: > [...] > I did some preliminary investigation and found a workaround to the > problem. It seems that building up the whole XML-RPC request > beforehand, then sending it all at once (rather than FORMATting the > HTTP > headers to the TCP stream one-by-one) fixes the problem. This is what > the attached patch does. I enclose it just in case someone else runs > into the same problem; it works for me, on the downside, it probably > causes the library to do more consing, although I did not check that > empirically. One difference between these two cases could be that the request is sent in multiple network packets in the first case, as a single packet in the second case (if it's not too big). > Strangely enough, the problem does not seem to occur with an > installation of the very same Java application on a single > (non-clustered) Glassfish running on newer versions of Ubuntu. Here I speculate wildly and without any evidence that the request consisting of multiple packets gets load-balanced across different server instances; I don't know how to verify that, though. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available URL: