[ 
https://issues.apache.org/jira/browse/TS-4796?focusedWorklogId=28050&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28050
 ]

ASF GitHub Bot logged work on TS-4796:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 03/Sep/16 06:34
            Start Date: 03/Sep/16 06:34
    Worklog Time Spent: 10m 
      Work Description: Github user oknet commented on the issue:

    https://github.com/apache/trafficserver/pull/947
  
    comments for codes:
    ```
          if (get_ev_events(pd, x) & (EVENTIO_READ | EVENTIO_ERROR)) {
            // ** set read.triggered if a epoll event of net has EVENTIO_READ 
or EVENTIO_ERROR bit set.
            vc->read.triggered = 1;
            // ** and put vc in read_ready_list
            if (!read_ready_list.in(vc)) {
              read_ready_list.enqueue(vc);
            } else if (get_ev_events(pd, x) & EVENTIO_ERROR) {
              // ** output an error message if a netvc already in ready_list 
got EVENTIO_ERROR.
              // check for unhandled epoll events that should be handled
              Debug("iocore_net_main", "Unhandled epoll event on read: 0x%04x 
read.enabled=%d closed=%d read.netready_queue=%d",
                    get_ev_events(pd, x), vc->read.enabled, vc->closed, 
read_ready_list.in(vc));
            }
          }
    ```
    The netvc always put in read_ready_list if it has EVENTIO_READ or 
EVENTIO_ERROR.
    
    ```
    #if defined(USE_EDGE_TRIGGER)
      // UnixNetVConnection *
      // ** for each netvc in read_ready_list
      while ((vc = read_ready_list.dequeue())) {
        if (vc->closed) // ** if the netvc mark closed
          close_UnixNetVConnection(vc, trigger_event->ethread);
        else if (vc->read.enabled && vc->read.triggered) //** if the netvc is 
enabled and triggered
          vc->net_read_io(this, trigger_event->ethread);
        else if (!vc->read.enabled) { //** if the netvc is not enabled
          read_ready_list.remove(vc);
    #if defined(solaris)
          if (vc->read.triggered && vc->write.enabled) {
            vc->ep.modify(-EVENTIO_READ);
            vc->ep.refresh(EVENTIO_WRITE);
            vc->writeReschedule(this);
          }   
    #endif
        }   
      }
    ```
    
    for your case, read.enabled is 0
    ```
        else if (!vc->read.enabled) { // if the netvc is not enabled
          read_ready_list.remove(vc);
    ```
    The vc is removed from read_ready_list.
    
    The below is my suggest:
    ```
          if (get_ev_events(pd, x) & (EVENTIO_READ | EVENTIO_ERROR)) {
            vc->read.triggered = 1;
    +      if (get_ev_events(pd, x) & EVENTIO_ERROR) {
    +        vc->read.error = 1;
    +      }
            if (!read_ready_list.in(vc)) {
              read_ready_list.enqueue(vc);
            } else if (get_ev_events(pd, x) & EVENTIO_ERROR) {
    ```
    and
    ```
        else if (vc->read.enabled && vc->read.triggered) //** if the netvc is 
enabled and triggered
          vc->net_read_io(this, trigger_event->ethread);
    +  else if (vc->read.error) {
    +    int err = 0, errlen = sizeof(int);
    +    if (getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &errlen) == -1) {
    +      err = errno;
    +    }
    +    if (err != EAGAIN && err != EINTR)
    +      vc->readSignalError(this, err);
    +  }
        else if (!vc->read.enabled) { //** if the netvc is not enabled
          read_ready_list.remove(vc);
    #if defined(solaris)
          if (vc->read.triggered && vc->write.enabled) {
            vc->ep.modify(-EVENTIO_READ);
            vc->ep.refresh(EVENTIO_WRITE);
    ```
    



Issue Time Tracking
-------------------

    Worklog Id:     (was: 28050)
    Time Spent: 3.5h  (was: 3h 20m)

> ATS not closing origin connections on first RST from client
> -----------------------------------------------------------
>
>                 Key: TS-4796
>                 URL: https://issues.apache.org/jira/browse/TS-4796
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Thomas Jackson
>            Assignee: Thomas Jackson
>          Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: <HttpSM.cc:2649 
> (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: <HttpSM.cc:892 
> (state_watch_for_client_abort)> (http) [0] 
> [&HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1173 
> (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1108 
> (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:203 
> (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:279 
> (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1213 
> (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: <HttpTunnel.cc:1373 
> (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to