On Mon, Mar 5, 2007, sergio <[EMAIL PROTECTED]> said: > >> ---------------------------------------------------------------------- >> paul - 05-Mar-07 10:56 >> ---------------------------------------------------------------------- >> So what is the bug then? What do you expect dbmail to do under these >> circumstances? >> > ok, but imho, in this case dbmail should write something into log, at > debug level..
Tech info: the kernel keeps track of all the incoming connections to a given ip/port and hands those connections off to the process that has created the socket to that ip/port when the process calls accept(). The kernel keeps a backlog of incoming connections. We default to asking the kernel for 16. See the BACKLOG parameter in the config file. If more than this many connections are waiting to be accept()-ed, the kernel refuses the connections. In the case of setting the maximum processes to 1, then showing that only 1 connection can proceed at a time... allow me to not so politely suggest that this reflects badly on one's comprehension of the number 1. As for logging: the sockets interface does not provide a way to know the size of the backlog. Not that I am aware of, at least. And anyways, this would just give a warning that you didn't do any of the basic work needed to configure your mail system for your mail needs. Bottom line: correct sizing of your DBMail system and correct configuration of your connection parameters is YOUR problem and always will be. Just search around for all of the HOWTO's that explain how to figure the sizing and adjust these parameters (including kernel parameters) for the myriad of network services that people like to set up and expect to magically scale up to hundreds or thousands of users without any planning or thought, and you'll see that the best thing we can do is provide the knobs (via config file options) and leave it to you to adjust those knobs as necessary. Anyways, sorry for the rant. I have a pet peeve against using bug tracking systems to report 'bugs' that boil down to the reporter not doing his/her homework on the issue first. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
