1 message in net.sourceforge.lists.courier-usersRe: [courier-users] Performance probl...
FromSent OnAttachments
Oliver BlasnikApr 7, 2001 4:50 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Performance problem on rfc822.size(it readswhole mail)Actions...
From:Oliver Blasnik (o.bl@nextra.de)
Date:Apr 7, 2001 4:50:22 pm
List:net.sourceforge.lists.courier-users

Hi Sam,

You wrote:

Probably, but that does mean that it is necessary to bend over backwards in order to accomodate someone else's bugs or poor coding.

Someone's for example the coders of msoe, and we here in Germany do have massive problems with the non-standard-headers (ex: username with 8-bit-chars). And, the mayority of our customers IS using that client, so we have to work around this problem. And we are not in a situation to tell our customers "sorry, your client sucks". HE is the one who says "Make that work like [a list of competors]. Now!".

Just _one_ of the things... And the reason to only use imapd and not the courier-mta...

There's a boundary that has to be drawn somewhere. Building a completely new caching infrastructure in order to make up for a poor client design, or doing something that is going to break pretty much every other IMAP client, out there, is way over the line.

Agree. Btw, noone said to integrate this (change behavior of 822.size) into the main code of courier.

Nope. Both Qmail and Courier-IMAP work fine out of the box, with the majority of the mail clients out there.

The majority _you_ see. Thats possibly true.

Except that 90% of the IMAP clients out there will never ask for the indexed or cached data anyway. They do their own caching, because that's necessary for offline mode. Indexing or caching IMAP metadata is mostly a waste of time.

And the other 10% waste 99% of the resources (in this, special case). Isn't that the normal way of life? ;)

No, but the added load on creating and maintaining useless cache files -- now THAT would be a major waste of resources.

There's a thing called "switch" or "parameter".

My submitted fixes 'bout mysql-authd were ignored again?

I do not have any patches from you.

| Message-ID: <015101c0b3b8$1b896f40$057affd4@oblath1000> | From: "Oliver Blasnik" <o.bl@nextra.de> | To: <cour@lists.sourceforge.net> | Subject: [courier-users] Authdaemons and TCP-Connections (MySQL, LDAP...) | Date: Fri, 23 Mar 2001 17:41:27 +0100 | | i just saw that problem of Jarand Moen (LDAP-Server restarting gets to | be annoying as far as the authdaemond-processes don't try to get the | connection up again). | | The same thing is with MySQL-authentication - and extremely if the | MySQL has a low connection timeout. In my opinion this IS A BUG of | the TCP-based authdaemons, and has to be fixed. [...] | Just a single retry to establish the connection again. If this fails, auth | will fail, but _then_ this is correct behaviour. And no more users asking | why they cannot login. [...] | I submitted this information twice (last time for 1.3.4), but no response | till now. Possibly we're going on with that _now_.

Btw, there's a "better" patch in use now, the old one was fixed on a special version - outdated now. It's missing context, my patchfile for authmysqllib.c is somewhat blown now...

patch: authmysqllib.c

if (mysql_query (mysql, querybuf)) { + /* PATCH BY OLIVER BLASNIK OF NEXTRA GERMANY. THIS DOES WORK NOW! */ + auth_mysql_cleanup(); /* connection lost? try again */ + if (do_connect()) { free(querybuf);return (0);}; + if (mysql_query (mysql, querybuf)) + { free(querybuf); auth_mysql_cleanup(); /* Server went down, that's OK, ** try again next time. */ return (0); + } + /* END OF PATCH */ } free(querybuf);

Please take a look at that posting, as there is another problem with configure.

Oliver