ExpatError errors should be handled to not generate the OOPSes

(Thanks to Francis for the diagnosis)

This seems to be a problem with an internal mailman process talking to our xmlrpc server (see "PATH_INFO: /mailinglists" in the OOPSes). In this case, the OOPS is valuable, in that it indicates something going wrong in our internal communications.

This means that the bug should go to registry; and that the expat errors in these oopses actually are not noise.

Barry. Can you look into what could be causing this? I cannot think of anything we have done recently to cause ill-formed markup. Since the other oopses regarding mailman have gone away, I wonder if debuging information is getting into the XML.

I actually don't think it's anything we're doing wrong. I think we're getting intermittent partial data. In the daily reports, I see a handful of these a week, definitely not every day.

I think we'd have to add some debugging output to catch the exception and print the received XML to diagnose this further. My suspicion is intermittent networking issues. It's probably worth spending some time debugging.

On Thu, 2009-08-20 at 15:26 +0000, Barry Warsaw wrote:
> I actually don't think it's anything we're doing wrong. I think we're
> getting intermittent partial data. In the daily reports, I see a
> handful of these a week, definitely not every day.

Do these relate the Connection refused errors we see in the oopses?

This is heartwarming.

The oops are coming from holdMessage() and they almost all spam. So the good news may be that this can be fixed. The bad news is that it'll probably increase the amount of spam moderators have to deal with :(