Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Antonio Menezes Leitao <aml@gi...> - 2005-06-08 21:48:39
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=20
(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?
CMUCL CVS release-19a 19a-release-20040728 + minimal debian patches
Both are running the debianized aserve 1.2.42+cvs.2005.02.21