From: knitti (knittigmail.com)
Date: Wed Dec 12 2007 - 15:03:04 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 12/12/07, Daniel Ouellet <danielpresscom.net> 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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]