Github user jpeach commented on the issue:

    https://github.com/apache/trafficserver/pull/701
  
    AFAICT we would get ``EPIPE`` when we write to a socket that has been 
closed. This would be an error because there is unwritten data that we can't 
write. We would get ``ECONNRESET`` reading from a socket that is closed. The 
other side closed the socket but we don't know whether that was premature or 
not (yet). Most places that I saw treated ``VC_EVENT_ERROR`` and 
``VC_EVENT_EOS`` similarly apart from logging.
    
    By the same logic, I agree that handling ``ECONNRESET`` specially in 
``write_to_net_io`` looks odd and could be a bug. Maybe the right change is to 
remove the ``ECONNRESET`` check in ``write_to_net_io``. Also in this code path, 
the return from ``UnixNetVConnection::load_buffer_and_write`` should never be 0 
because we never try to write 0 bytes.
    
    So consider:
    ```C
    diff --git a/iocore/net/UnixNetVConnection.cc 
b/iocore/net/UnixNetVConnection.cc
    index b52985c..bc9764d 100644
    --- a/iocore/net/UnixNetVConnection.cc
    +++ b/iocore/net/UnixNetVConnection.cc
    @@ -535,11 +535,9 @@ write_to_net_io(NetHandler *nh, UnixNetVConnection 
*vc, EThread *thread)
           }
           return;
         }
    -    if (!r || r == -ECONNRESET) {
    -      vc->write.triggered = 0;
    -      write_signal_done(VC_EVENT_EOS, nh, vc);
    -      return;
    -    }
    +    // A write of 0 makes no sense since we tried to write more than 0. 
Either
    +    // we wrote something or we got an error.
    +    ink_assert(r < 0);
         vc->write.triggered = 0;
         write_signal_error(nh, vc, (int)-total_written);
         return;
    ```
    



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to