On 12/12/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote: > knitti wrote: > > The problem would be to "forget" calling ap_bclose() after ending a > > connection, either because all data has been sent or the connection has > > been aborted. What I can read with some confidence, is that keeping a > > socket open beyond sending any data is not intentional, and there is > > nothing (for me) which suggests that it would happen at all. > > Logically if that was the case, wouldn't you think you would run out of > sockets in just a few minutes after starting httpd? I am not saying > there isn't any bugs in httpd, or that there is. Fair to assume there is > some, but to that extend, I couldn't imagine so. Just think about it for > a second. What the effect of it would be if that was the case?
I think you misunderstood me. I meant I don't see any obvious occasion in which the problem I assumed (forgetting ap_bclose() ) would occur. So I don't see any bug (surpise), but something occurs. So either I don't see the bug because its not obvious (surprise, again), or my assumption (ap_bclose() not called) is wrong. My question: would not calling ap_bclose() show this behaviour ? > - Application needs sockets and send request to create and destroy them > and keep using them after they are created. Who does that, kernel or > application? I assume the kernel creates the actual socket, but the app keeps it as long as it wants (or longer ;-) > - Who receive the sockets creation and destroy requests and will create > them or destroy them and pass the handle to the application when ready. > The Kernel, or the applications? > > - Who is handling the signaling, meaning handshake, opening, close_wait, > retransmitions, etc. Application or kernel? > > - So, in the end, if a socket is in close_wait, is it the application, > or the kernel at that point? Meaning, was it already requested to be > close and is now a signaling issue, or an application that hasn't asked > to close the socket yet? (;> I *assume* that it is the application forgetting to close(), because if the kernel "forgets" to close() something what is more or less a file, we would also have massive stale open files being around. > - If jam in close_wait state, is it because it hasn't send the ACK on > the request from the client to close the socket? > > - Or is it that it did send the ACK to the client and is now waiting on > the final ACK from that client to do it? > > - Or is it that it reach that point because it was an none fully open > three way handshake establish connection to start with may be? > > - Or it is because the client just open a socket, get what it needed and > didn't bother to do the proper closing of the sockets as it should be? _please_, read my last mails, or look at a TCP state diagram. > - Now, where is the application, in the case httpd involved here? CLOSE_WAIT is a defined state. The most simple explaination is not closing the socket even after recognizing there is nothing more to read from it. > - Where can keep alive in httpd help, or not? > > - Where pf proxy help or not? > > - Where keep alive in tcp stack (sysctl) help or not? these three questions I simply don't understand. Please rephrase. > That's why there isn't a single answer to the questions here and it will > always depend on your specific setup, traffic patterns and load, etc. I seems we are here of different opinions. I'm more or less convinced now, that there is a bug not closing the socket even after httpd has nothing more to send. Under the assumption my interpretation of the problem is not fundamentally flawed. > Example, you could reduce the keep alive in sysctl a lots if you want to > help the close_wait, but at the same time this will increase all the > exchange messages between valid connections as well. So, on one hand to > will affect the delay in closing your sockets sooner, but at the same > time you will increase the load on other already active connections. well, I think turnig the wrong knobs will do harm, there you are right. tuning TCP keep alives would be the wrong knob > left, unless it does give you a problem, other then a feeling of wanting > it to look different, you should put it to rest I think. unless I can reproduce it, I will also let it rest after being convinced of not finding the bug by reading the code alone ;) --knitti
