Uploaded image for project: 'Traffic Server'
  1. Traffic Server
  2. TS-4343

When ATS hits `proxy.config.http.origin_max_connections`, the requests queued will not abort even if client aborts

Details

    • Bug
    • Status: Reopened
    • Major
    • Resolution: Unresolved
    • None
    • sometime
    • Network
    • None

    Description

      While testing my patch for TS-4341 I've noticed that once a request is queued waiting for max connections, ATS will not abort the request even if the client has completely disconnected. It seems that ATS is only setting up a consumer of the UA tunnel if there is a post body-- and as such we never see the socket close on us. Still digging into this some, but this seems like a problem

      Attachments

        Issue Links

          Activity

            jacksontj Thomas Jackson added a comment -

            From some additional investigation, it seems that the HttpSM makes an assumption that if the client disconnects it just a half close (https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L846), which doesn't make a lot of sense to me-- if the client disconnected, there is no reason to finish the origin request or anything-- IMO at that point we should drop the request and mark it as aborted. I can't seem to find any reason we shouldn't shut it down at that point (esp. since the underlying socket is already closed at this point).

            jacksontj Thomas Jackson added a comment - From some additional investigation, it seems that the HttpSM makes an assumption that if the client disconnects it just a half close ( https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L846 ), which doesn't make a lot of sense to me-- if the client disconnected, there is no reason to finish the origin request or anything-- IMO at that point we should drop the request and mark it as aborted. I can't seem to find any reason we shouldn't shut it down at that point (esp. since the underlying socket is already closed at this point).
            jamespeach James Peach added a comment -

            If the client closed the write end of it's socket, it can still be receiving the response.

            jamespeach James Peach added a comment - If the client closed the write end of it's socket, it can still be receiving the response.
            jacksontj Thomas Jackson added a comment -

            If I'm not mistaken a client cannot close just the write end of the socket. In this half-open case the client has initiated a teardown. So, IMO in this case we can send any bytes we have in memory-- but if we still have an outstanding connection to the origin there is no reason to leave that origin connection running, as once we get bytes from the origin we'll have nowhere to send it to.

            I also did some more testing, and it seems that this case I'm describing is only on requests with no body if the origin hasn't started sending a body back-- seems just like an oversight in the SM. (the specific issue is I send a GET, sever doesn't send bytes, client DCs, connection to origin completes and is logged as a successful request).

            So, from that I think it should just mimic the behavior of what the POSTs are doing-- namely that we stop the downstream connection, send whatever bytes we have, then close the client connection as well.

            Sound fair?

            jacksontj Thomas Jackson added a comment - If I'm not mistaken a client cannot close just the write end of the socket. In this half-open case the client has initiated a teardown. So, IMO in this case we can send any bytes we have in memory-- but if we still have an outstanding connection to the origin there is no reason to leave that origin connection running, as once we get bytes from the origin we'll have nowhere to send it to. I also did some more testing, and it seems that this case I'm describing is only on requests with no body if the origin hasn't started sending a body back-- seems just like an oversight in the SM. (the specific issue is I send a GET, sever doesn't send bytes, client DCs, connection to origin completes and is logged as a successful request). So, from that I think it should just mimic the behavior of what the POSTs are doing-- namely that we stop the downstream connection, send whatever bytes we have, then close the client connection as well. Sound fair?

            People

              jacksontj Thomas Jackson
              jacksontj Thomas Jackson
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: