Hi, I'm sending this message both to SBCL and CMUCL mailing lists as the problem I will describe happens in both implementations.
While using the portable allegro serve and, more particularly, the do-http-request function to invoke a web service that returns a XML form, I noticed that the xml parser sometimes (most of the times, in fact) couldn't parse the result. The exact same invocation works perfectly in Allegro 7.0. The reason why the xml parser fails is the fact that, most of the times, the do-http-request call returns a string that contains one extra character in the middle of a xml tag, thus making it invalid. After much testing, I noticed that the problem occurs more or less randomly. Sometimes, it works, sometimes it doesn't (i.e., sometimes there's no extra character, sometimes there's one extra character but, as I mentioned previously, the non-working cases are much more frequent). I'm absolutely sure the server always returns the exact same answer so the blame is on the client. After digging on the aserve source files, I noticed that the do-http-request function calls (client-request-read-sequence ans creq :start start) in a loop to consume the server answer. The reason why (sometimes) there's an extra character in the do-http-request result is because (sometimes) this function returns a sequence that contains the extra character. When that happens, at least in all cases I tested, the extra character is on the first position of the sequence (note that, AFAICS, there are no missing characters in the sequence). I noted that client-request-read-sequence is implemented on top of read-sequence and I got the feeling that this was some sort of race condition (as usually happens with randomly-occurring bugs) so I made a small experiment: I included a (sleep 0.01) before the call to client-request-read-sequence. Both sbcl and cmucl worked perfectly with this "fix" but, obviously, this isn't a good solution. Is there's anything I can do to help you track this bug? I'm using CMUCL CVS release-19a 19a-release-20040728 + minimal debian patches and SBCL 0.9.1.1 Both are running the debianized aserve 1.2.42+cvs.2005.02.21 Best regards, Ant�nio Leit�o.
