Paul J Stevens wrote:
The wiki seems almost empty 'cept for headings of wholesale code-method
changes (new api for message retrieval, header caching tables blah blah
blah). I can not see how these changes would impact my users (they
almost never search), and using a new api may introduce as many bugs as
it resolves.
Mmmm, imo searches are rarely used because no free imap server does them any way
near fast enough.
Your problems though are at the heart of why I took dbmail upon myself. I didn't
write dbmail. But the problems you face are why I'm trying to fix the code. Your
clients take 20 minutes to append a message to the sent folder because the
server just hung up, and the client won't reconnect for 20 minutes or just can't
get a new connection.
I figured as much.
Long delays for loading message bodies are often also an indication that the
server crashed out, or that the mime parser just got into a runaway loop. That
code has gone unmaintained since before 1.2 afaik. And for some pretty good (or
rather bad) reasons. So yes: fixing problems will cause new bugs, but at least
they will be different (hopefully less serious) bugs. Also, there will be
someone who cares enough to fix them, or else be readable, well designed,
supported by regression tests so someone else can fix them.
Yeah, I am all for that. I don't mind bugs in code that is maintained
and maintainable. At least I could expect progress.
The performance issues are not ones of typical performance (you know,
several seconds to do things). They are ones where progress dialogs stay
on the user's machines for 20 minutes just copying a message to the sent
folder. The server is showing .04% CPU utilization.
You're describing a fatal bug. Calling that a performance issue, is a matter of
definition I imagine. Still, once you get past those fatal server crashes,
people will scale up and start expecting more features and better performance.
Ah, jut noticed nfgd has come back, with a new version. Check this out:
....
....
Bah, it seems worse than before.
....
Hardly likely. Changes from 2.0.4 to 2.0.7 where almost exclusively about the
server pool, which doesn't use any kind of double-linked list structure.
A google search on this glibc thing shows that there are indications this may be
related to your binutils toolchain. Are you running special versions of glibc
and friends? I can't reproduce this.
I am using a stock debian sarge distro, no special glibc thingies.
However, I am glad glibc gives these messages: I can use them to track
down the locus of the problem (hopefully), which existed long before
glibc started giving these messages.
--
Dominic Amann, Linux Based Solutions Ltd., <http://www.lbs.ca/>
3020 Keele Street, Downsview, ON M3M 2H3
Tel: (416) 270-4587
