Hi
Leif Jackson wrote:
Dear Dev,
I belive I have found in 2.0cvs a few places where the db result is not
freed under mysql, This was causing my imapd to get outragiously large,
like in the 100Mb range, after pulling only about 10000 headers. The
patch I have attached also fixes a minor issue with dbmail and mysql,
and that is that after an overnight the mysql server may timeout the
connections and there isn't a reconnect check in the code for
check_connection like there is in the pgsql driver. I added that as well
as added the mysql specific auto-reconnect option. There is also a minor
missing free in the the authsql.c with the escaped user str.
Great work. I'll have a look at it tomorrow morning!
I also belive there is a leak still with one of the allocated list's
(list.c) not being list freeded, All this memory work was traced with
dmalloc which is a fantastic package, and allows for logfiles per pid as
well as line numbers.
Sounds good. their website (dmalloc.com) is unreachable at the moment,
but I'll take a look at it.
Please review the diff and apply if it suites. I really apreciate
everyones hard work on this project and I am very excited with the
progress and overall stablity of the 2.0 branch as it is now. I have
been running it (after my patches) for about a week now under light load
but have put it under some major stress with the postal stress test
package and it has done very well.
I'll review it asap.
Does the dbmail list know of a better testing suite that fully supports
imap or may have more features?
I mostly use my normal mail client and sometimes some python scripts.
There's no substitute for testing in production though. I've been using
dbmail 2.0 in parallel with dbmail 1.2 for 1 1/2 months now. My mail
gets sent to both dbmail 2.0 and dbmail 1.2 (so I get to read every
email twice ;) ).
Thanks for the work,
Ilja
--
IC&S
Stadhouderslaan 57
3583 JD Utrecht
PGP-key:
http://www.ic-s.nl/keys/ilja.txt
