[ 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)