Re: [RFC] removing comm half-closed mechanism

On 10/13/2013 06:34 AM, Amos Jeffries wrote:
> While working on redesign of the ConnStateData functionality I have come
> to suspect that the half-closed FD monitoring feature is possibly
> defunct now.

Do you mean that the feature no longer works? If yes, does it imply that
virtually nobody actually needs it (since there are no bug reports that
it is broken)?

> In particular ConnStateData now provides stopReceiving()/stopSending()
> members to explicitly finish closing the connection at an appropriate
> time in the traffic and a set of accessors to monitor the half-closed
> nature of connections in a much more deterministic directional way.

The new stopReceiving()/stopSending() code does not replace half-closed
connection handling AFAICT. The new code works on HTTP level.
Half-closed code is about TCP. One is not a substitute for the other. It
may be possible to combine them, of course, but I do not yet see why
that would be better than keeping them separate.

> It
> would seem the FD monitoring handler which is set for half-closed might
> still be useful, but this can be moved to a ConnStateData handler instead.

Yes, but not without a performance penalty. Assuming 100 concurrent
half-closed connections, this move would result in going from one timed
event every second to 100 timed events every second. Since timed events
are not optimized, that could be a noticeable change in environments
that have many half-closed connections. I do not know whether such
environments exist, but this could be the rationale for implementing
half-closed monitoring in a centralized fashion.

> Anyone have a reason why we should keep all the half-closed code in
> comm.cc ?

Your email seems to imply that you want to _move_ the half-closed code
instead of _removing_ it as the Subject implies. Please clarify what you
are proposing.

If we decide that half-closed feature is still needed, I see three
reasons to keep its code in comm.cc:

* It is already there.

* A centralized implementation is much more efficient (see above).

* In theory, the server connections may be half-closed as well, and we
might want to monitor them for half-closure some day. I am not aware of
any servers using half-closed connections today and this is a rather
weak argument, of course.

What are the reasons to move the feature implementation to ConnStateData?

Thank you,

Alex.
Received on Tue Oct 15 2013 - 18:54:37 MDT