[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1052
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/907/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30005)
Time Spent: 3h 40m  (was: 3.5h)

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/907/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Sep/16 01:04
Start Date: 30/Sep/16 01:04
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/802/ for details.
 



Issue Time Tracking
---

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

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/802/ for details.
 



---
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.
---

[jira] [Comment Edited] (TS-4821) Make hwloc a required dependency

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534640#comment-15534640
 ] 

James Peach edited comment on TS-4821 at 9/30/16 1:03 AM:
--

FWIW on https://ucloud.cn/ VMs running Ubuntu 14.04, hwloc 1.8 always crashes 
with SIGFPE, making Traffic Server somewhat unusable :(

{noformat}
$ gdb --args hwloc-info
...
(gdb) run
Starting program: /usr/bin/hwloc-info

Program received signal SIGFPE, Arithmetic exception.
0x77bca83e in ?? () from /usr/lib/x86_64-linux-gnu/libhwloc.so.5
(gdb) where
#0  0x77bca83e in ?? () from /usr/lib/x86_64-linux-gnu/libhwloc.so.5
#1  0x77bcc3a1 in ?? () from /usr/lib/x86_64-linux-gnu/libhwloc.so.5
#2  0x77bcc71b in ?? () from /usr/lib/x86_64-linux-gnu/libhwloc.so.5
#3  0x77ba5d4b in ?? () from /usr/lib/x86_64-linux-gnu/libhwloc.so.5
#4  0x77ba6d64 in hwloc_topology_load () from 
/usr/lib/x86_64-linux-gnu/libhwloc.so.5
#5  0x94b0 in ?? ()
#6  0x777f6f45 in __libc_start_main (main=0x8e17, argc=1, 
argv=0x7fffe658, init=, fini=,
rtld_fini=, stack_end=0x7fffe648) at libc-start.c:287
#7  0x5809 in ?? ()
(gdb) quit
{noformat}


was (Author: jamespeach):
FWIW on https://ucloud.cn/ VMs running Ubuntu 14.04, hwloc 1.8 always crashes 
with SIGFPE, making Traffic Server somewhat unusable :(

> Make hwloc a required dependency
> 
>
> Key: TS-4821
> URL: https://issues.apache.org/jira/browse/TS-4821
> Project: Traffic Server
>  Issue Type: Task
>  Components: Build
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> hwloc is available on every platform we support. We do a lot of dances in the 
> code to make this optional, and we should probably just require it.



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

[jira] [Commented] (TS-4821) Make hwloc a required dependency

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534640#comment-15534640
 ] 

James Peach commented on TS-4821:
-

FWIW on https://ucloud.cn/ VMs running Ubuntu 14.04, hwloc 1.8 always crashes 
with SIGFPE, making Traffic Server somewhat unusable :(

> Make hwloc a required dependency
> 
>
> Key: TS-4821
> URL: https://issues.apache.org/jira/browse/TS-4821
> Project: Traffic Server
>  Issue Type: Task
>  Components: Build
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> hwloc is available on every platform we support. We do a lot of dances in the 
> code to make this optional, and we should probably just require it.



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

[jira] [Work logged] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 23:57
Start Date: 29/Sep/16 23:57
Worklog Time Spent: 10m 
  Work Description: Github user shukitchan commented on the issue:

https://github.com/apache/trafficserver/pull/1065
  
it looks fine.


Issue Time Tracking
---

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

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> 

[GitHub] trafficserver issue #1065: TS-4911: ts_lua plugin is modified to clear 'clie...

[shukitchan]

Github user shukitchan commented on the issue:

https://github.com/apache/trafficserver/pull/1065
  
it looks fine.


---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 23:14
Start Date: 29/Sep/16 23:14
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/801/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 2)
Time Spent: 4h 20m  (was: 4h 10m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/801/ for details.
 



---
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.
---

[jira] [Resolved] (TS-4899) Http2ClientSession object leaks

[Susan Hinrichs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Susan Hinrichs resolved TS-4899.

Resolution: Fixed

> Http2ClientSession object leaks
> ---
>
> Key: TS-4899
> URL: https://issues.apache.org/jira/browse/TS-4899
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Running master plus proposed fix for TS-4813 (without this fix, 
> traffic_server crashes very quickly).  
> After a short time (10 minutes), I noticed that the process memory 
> utilization was growing.  I took the machine out of rotation and waited for 
> existing connections to drain.  The memory use summary from SIGUSR1 shows 
> that many (most?) Http2ClientSession, Http2Stream, and Http1ClientSession 
> objects are not being freed.



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

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 23:11
Start Date: 29/Sep/16 23:11
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/906/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29997)
Time Spent: 4h 10m  (was: 4h)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/906/ for details.
 



---
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.
---

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/905/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1066
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/905/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29996)
Time Spent: 4h  (was: 3h 50m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 23:01
Start Date: 29/Sep/16 23:01
Worklog Time Spent: 10m 
  Work Description: Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Oh god sorry. I'll get the clang formatting right on the first time someday.


Issue Time Tracking
---

Worklog Id: (was: 29995)
Time Spent: 3h 50m  (was: 3h 40m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[ericcarlschwartz]

Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Oh god sorry. I'll get the clang formatting right on the first time someday.


---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:56
Start Date: 29/Sep/16 22:56
Worklog Time Spent: 10m 
  Work Description: Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
The same request over http/2 has the additional h2 marker as follows:

`via: https/1.1 yahoo.com (ApacheTrafficServer), http/1.1 h2 tls/1.2 tcp 
ipv4 ubuntu (ApacheTrafficServer/7.1.0)`


Issue Time Tracking
---

Worklog Id: (was: 29993)
Time Spent: 3h 40m  (was: 3.5h)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[ericcarlschwartz]

Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
The same request over http/2 has the additional h2 marker as follows:

`via: https/1.1 yahoo.com (ApacheTrafficServer), http/1.1 h2 tls/1.2 tcp 
ipv4 ubuntu (ApacheTrafficServer/7.1.0)`


---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:55
Start Date: 29/Sep/16 22:55
Worklog Time Spent: 10m 
  Work Description: Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
As a heads up, this simplifies things a bit, always relying on the HttpSM 
`populate_client_protocol` call on the client side. This changes our via header 
even for http/1.1.

An old via header that read:

`Via: https/1.1 ats2.fp.gq1.yahoo.com (ApacheTrafficServer), http/1.1 
ubuntu (ApacheTrafficServer/7.1.0)`

Would now read:

`Via: https/1.1 ats2.fp.gq1.yahoo.com (ApacheTrafficServer), http/1.1 
tls/1.2 tcp ipv4 ubuntu (ApacheTrafficServer/7.1.0)`


Issue Time Tracking
---

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

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[ericcarlschwartz]

Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
As a heads up, this simplifies things a bit, always relying on the HttpSM 
`populate_client_protocol` call on the client side. This changes our via header 
even for http/1.1.

An old via header that read:

`Via: https/1.1 ats2.fp.gq1.yahoo.com (ApacheTrafficServer), http/1.1 
ubuntu (ApacheTrafficServer/7.1.0)`

Would now read:

`Via: https/1.1 ats2.fp.gq1.yahoo.com (ApacheTrafficServer), http/1.1 
tls/1.2 tcp ipv4 ubuntu (ApacheTrafficServer/7.1.0)`


---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:53
Start Date: 29/Sep/16 22:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/800/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29991)
Time Spent: 3h 20m  (was: 3h 10m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/800/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:51
Start Date: 29/Sep/16 22:51
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/904/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29990)
Time Spent: 3h 10m  (was: 3h)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/904/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:48
Start Date: 29/Sep/16 22:48
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/799/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29989)
Time Spent: 3h  (was: 2h 50m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #1066: [TS-4457] Via header always reports http1

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1066
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/799/ for details.
 



---
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.
---

[GitHub] trafficserver pull request #1066: [TS-4457] Via header always reports http1

[ericcarlschwartz]

GitHub user ericcarlschwartz opened a pull request:

https://github.com/apache/trafficserver/pull/1066

[TS-4457] Via header always reports http1

old PR here. I majorly botched the rebase, sorry: 
https://github.com/apache/trafficserver/pull/954

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ericcarlschwartz/trafficserver TS-4457

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1066.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1066


commit 8c4f4724bb39e9156cf8810e6757dcf3c5aea837
Author: ericcarlschwartz 
Date:   2016-09-29T22:43:54Z

[TS-4457] Via header always reports http1




---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:44
Start Date: 29/Sep/16 22:44
Worklog Time Spent: 10m 
  Work Description: GitHub user ericcarlschwartz opened a pull request:

https://github.com/apache/trafficserver/pull/1066

[TS-4457] Via header always reports http1

old PR here. I majorly botched the rebase, sorry: 
https://github.com/apache/trafficserver/pull/954

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ericcarlschwartz/trafficserver TS-4457

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1066.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1066


commit 8c4f4724bb39e9156cf8810e6757dcf3c5aea837
Author: ericcarlschwartz 
Date:   2016-09-29T22:43:54Z

[TS-4457] Via header always reports http1




Issue Time Tracking
---

Worklog Id: (was: 29988)
Time Spent: 2h 50m  (was: 2h 40m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver issue #954: [TS-4457] Via header always reports http1

[ericcarlschwartz]

Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/954
  
h sorry this is bad i'm going to close it


---
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.
---

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:38
Start Date: 29/Sep/16 22:38
Worklog Time Spent: 10m 
  Work Description: Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/954
  
h sorry this is bad i'm going to close it


Issue Time Tracking
---

Worklog Id: (was: 29985)
Time Spent: 2.5h  (was: 2h 20m)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[jira] [Work logged] (TS-4457) Via header always reports http1

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:38
Start Date: 29/Sep/16 22:38
Worklog Time Spent: 10m 
  Work Description: Github user ericcarlschwartz closed the pull request at:

https://github.com/apache/trafficserver/pull/954


Issue Time Tracking
---

Worklog Id: (was: 29986)
Time Spent: 2h 40m  (was: 2.5h)

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.1.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[GitHub] trafficserver pull request #954: [TS-4457] Via header always reports http1

[ericcarlschwartz]

Github user ericcarlschwartz closed the pull request at:

https://github.com/apache/trafficserver/pull/954


---
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.
---

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/798/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:25
Start Date: 29/Sep/16 22:25
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/798/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29983)
Time Spent: 3h 20m  (was: 3h 10m)

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:23
Start Date: 29/Sep/16 22:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/903/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29982)
Time Spent: 3h 10m  (was: 3h)

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/903/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:21
Start Date: 29/Sep/16 22:21
Worklog Time Spent: 10m 
  Work Description: Github user calavera commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1062#discussion_r81247196
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -356,8 +356,6 @@ Http2Stream::transaction_done()
 
   if (closed) {
 // Safe to initiate SSN_CLOSE if this is the last stream
-if (cross_thread_event)
-  cross_thread_event->cancel();
 // Schedule the destroy to occur after we unwind here.  IF we call 
directly, may delete with reference on the stack.
--- End diff --

If do_io_close set the event again, would it make sense to check if the 
even is cancelled rather than removing this code? In our tests, this doesn't 
happen, but I'm not familiar with the code to be sure it never happens.


Issue Time Tracking
---

Worklog Id: (was: 29981)
Time Spent: 1h 10m  (was: 1h)

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver pull request #1062: [TS-4908] Remove duplicated cancelling act...

[calavera]

Github user calavera commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1062#discussion_r81247196
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -356,8 +356,6 @@ Http2Stream::transaction_done()
 
   if (closed) {
 // Safe to initiate SSN_CLOSE if this is the last stream
-if (cross_thread_event)
-  cross_thread_event->cancel();
 // Schedule the destroy to occur after we unwind here.  IF we call 
directly, may delete with reference on the stack.
--- End diff --

If do_io_close set the event again, would it make sense to check if the 
even is cancelled rather than removing this code? In our tests, this doesn't 
happen, but I'm not familiar with the code to be sure it never happens.


---
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.
---

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:18
Start Date: 29/Sep/16 22:18
Worklog Time Spent: 10m 
  Work Description: Github user calavera commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1062#discussion_r81246655
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -356,8 +356,6 @@ Http2Stream::transaction_done()
 
   if (closed) {
 // Safe to initiate SSN_CLOSE if this is the last stream
-if (cross_thread_event)
-  cross_thread_event->cancel();
 // Schedule the destroy to occur after we unwind here.  IF we call 
directly, may delete with reference on the stack.
--- End diff --

Sorry, I agree that the title and description is misleading, I meant to say 
cancelling, not closing. Modifying title and description to be more correct.


Issue Time Tracking
---

Worklog Id: (was: 29980)
Time Spent: 1h  (was: 50m)

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver pull request #1062: [TS-4908] Remove duplicated closing contin...

[calavera]

Github user calavera commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1062#discussion_r81246655
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -356,8 +356,6 @@ Http2Stream::transaction_done()
 
   if (closed) {
 // Safe to initiate SSN_CLOSE if this is the last stream
-if (cross_thread_event)
-  cross_thread_event->cancel();
 // Schedule the destroy to occur after we unwind here.  IF we call 
directly, may delete with reference on the stack.
--- End diff --

Sorry, I agree that the title and description is misleading, I meant to say 
cancelling, not closing. Modifying title and description to be more correct.


---
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.
---

[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:16
Start Date: 29/Sep/16 22:16
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/902/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29979)
Time Spent: 3h  (was: 2h 50m)

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/902/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:14
Start Date: 29/Sep/16 22:14
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/797/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29978)
Time Spent: 2h 50m  (was: 2h 40m)

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/797/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:11
Start Date: 29/Sep/16 22:11
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Pushed a new branch that addresses several asserts I was seeing in 
production.  Just rebased to pick up the memory leak fix.  


Issue Time Tracking
---

Worklog Id: (was: 29977)
Time Spent: 2h 40m  (was: 2.5h)

> HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
> 
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: crash
> Fix For: 7.1.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event == 
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS || 
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive == 
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*, 
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int, 
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int, 
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int, 
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}



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

[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Pushed a new branch that addresses several asserts I was seeing in 
production.  Just rebased to pick up the memory leak fix.  


---
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.
---

[jira] [Work logged] (TS-4899) Http2ClientSession object leaks

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:09
Start Date: 29/Sep/16 22:09
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

https://github.com/apache/trafficserver/pull/1055


Issue Time Tracking
---

Worklog Id: (was: 29976)
Time Spent: 1h 20m  (was: 1h 10m)

> Http2ClientSession object leaks
> ---
>
> Key: TS-4899
> URL: https://issues.apache.org/jira/browse/TS-4899
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Running master plus proposed fix for TS-4813 (without this fix, 
> traffic_server crashes very quickly).  
> After a short time (10 minutes), I noticed that the process memory 
> utilization was growing.  I took the machine out of rotation and waited for 
> existing connections to drain.  The memory use summary from SIGUSR1 shows 
> that many (most?) Http2ClientSession, Http2Stream, and Http1ClientSession 
> objects are not being freed.



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

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 22:08
Start Date: 29/Sep/16 22:08
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1062#discussion_r81245130
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -356,8 +356,6 @@ Http2Stream::transaction_done()
 
   if (closed) {
 // Safe to initiate SSN_CLOSE if this is the last stream
-if (cross_thread_event)
-  cross_thread_event->cancel();
 // Schedule the destroy to occur after we unwind here.  IF we call 
directly, may delete with reference on the stack.
--- End diff --

This seems like a reasonable cleanup unless the earlier do_io_close could 
cause the cross_thread_event to be set again.  NULLing out cross_thread_event 
earlier and adding an assert here would be reasonable.

However this fix doesn't seem to match the title.  Canceling the event is 
not going to cause the close to happen twice.


Issue Time Tracking
---

Worklog Id: (was: 29975)
Time Spent: 50m  (was: 40m)

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver pull request #1055: TS-4899: Http2ClientSession object leaks.

[shinrich]

Github user shinrich closed the pull request at:

https://github.com/apache/trafficserver/pull/1055


---
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.
---

[GitHub] trafficserver pull request #1062: [TS-4908] Remove duplicated closing contin...

[shinrich]

Github user shinrich commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1062#discussion_r81245130
  
--- Diff: proxy/http2/Http2Stream.cc ---
@@ -356,8 +356,6 @@ Http2Stream::transaction_done()
 
   if (closed) {
 // Safe to initiate SSN_CLOSE if this is the last stream
-if (cross_thread_event)
-  cross_thread_event->cancel();
 // Schedule the destroy to occur after we unwind here.  IF we call 
directly, may delete with reference on the stack.
--- End diff --

This seems like a reasonable cleanup unless the earlier do_io_close could 
cause the cross_thread_event to be set again.  NULLing out cross_thread_event 
earlier and adding an assert here would be reasonable.

However this fix doesn't seem to match the title.  Canceling the event is 
not going to cause the close to happen twice.


---
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.
---

[jira] [Work logged] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 19:28
Start Date: 29/Sep/16 19:28
Worklog Time Spent: 10m 
  Work Description: GitHub user brkishore opened a pull request:

https://github.com/apache/trafficserver/pull/1065

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook.

This is to backport PR on to 6.2.x.
globalHookHandler() [ts_lua.c] and 
ts_lua_http_cont_handler()[ts_lua_util.c] are modified to clear 
'client_response_hdrp' pointer when it enters SEND_RESPONSE_HDR hook.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brkishore/trafficserver TS-4911-BP-6.2.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1065.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1065


commit eabb0136a2f22ffac2366e013d80263ae15c6f4d
Author: rb304g 
Date:   2016-09-29T18:42:56Z

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook.




Issue Time Tracking
---

Worklog Id: (was: 29968)
Time Spent: 20m  (was: 10m)

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward 

[GitHub] trafficserver pull request #1065: TS-4911: ts_lua plugin is modified to clea...

[brkishore]

GitHub user brkishore opened a pull request:

https://github.com/apache/trafficserver/pull/1065

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook.

This is to backport PR on to 6.2.x.
globalHookHandler() [ts_lua.c] and 
ts_lua_http_cont_handler()[ts_lua_util.c] are modified to clear 
'client_response_hdrp' pointer when it enters SEND_RESPONSE_HDR hook.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brkishore/trafficserver TS-4911-BP-6.2.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1065.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1065


commit eabb0136a2f22ffac2366e013d80263ae15c6f4d
Author: rb304g 
Date:   2016-09-29T18:42:56Z

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook.




---
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.
---

[jira] [Work logged] (TS-4897) Unbound growth of number of memory maps for traffic_server under SSL termination load when ssl_ticket_enabled=0

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 19:22
Start Date: 29/Sep/16 19:22
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/1050
  
Patch for making the advice configurable.


Issue Time Tracking
---

Worklog Id: (was: 29967)
Time Spent: 1h 50m  (was: 1h 40m)

> Unbound growth of number of memory maps for traffic_server under SSL 
> termination load when ssl_ticket_enabled=0
> ---
>
> Key: TS-4897
> URL: https://issues.apache.org/jira/browse/TS-4897
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Can Selcik
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The number of {{\[anon\]}} memory regions mapped to the {{traffic_server}} 
> process displays unbound growth until the kernel thresholds are reached and 
> the process is terminated. 
> This happens when ATS is used to terminate SSL and {{ssl_ticket_enabled=0}} 
> in {{ssl_multicert.config}}.
> We've experienced this issue on our staging and production hosts and were 
> able to replicate it with the above configuration under high volume HTTPS 
> load. We didn't experience this with {{5.2.x}} and it will make sense why at 
> the end.
> While generating {{https}} traffic with {{siege}} or {{ab}}, the issue can be 
> observed with:
> {{watch "pmap $(pidof traffic_server) | wc -l"}}
> {{git bisect}} pointed us to: 
> Turns out a no-op {{ats_madvise}} hides the symptoms of the issue.
> Going in deeper, we realize that {{ssl_ticket_enabled}} option is relevant 
> because after enabling the {{ssl.session_cache}} tag, we see that ATS doesn't 
> manage its own session cache for SSL, it is done by the library instead. In 
> that case, the code path doing the problematic allocation within ATS doesn't 
> get executed often since OpenSSL takes care of the session tokens.
> But why does this happen? It happens because {{MADV_DONTDUMP}} is passed to 
> {{posix_madvise}} even though {{MADV_DONTDUMP}} is not a valid flag for 
> {{posix_madvise}} as it is not a drop-in replacement to {{madvise}}.
> Looking at {{}}:
> {noformat}
>  87 /* Advice to `madvise'.  */
>  88 #ifdef __USE_BSD
>  89 # define MADV_NORMAL▸ 0▸/* No further special treatment.  */
>  90 # define MADV_RANDOM▸ 1▸/* Expect random page references.  */
>  91 # define MADV_SEQUENTIAL  2▸/* Expect sequential page references. 
>  */
>  92 # define MADV_WILLNEED▸   3▸/* Will need these pages.  */
>  93 # define MADV_DONTNEED▸   4▸/* Don't need these pages.  */
>  94 # define MADV_REMOVE▸ 9▸/* Remove these pages and resources.  
> */
>  95 # define MADV_DONTFORK▸   10▸   /* Do not inherit across fork.  */
>  96 # define MADV_DOFORK▸ 11▸   /* Do inherit across fork.  */
>  97 # define MADV_MERGEABLE▸  12▸   /* KSM may merge identical pages.  */
>  98 # define MADV_UNMERGEABLE 13▸   /* KSM may not merge identical pages. 
>  */
>  99 # define MADV_DONTDUMP▸   16/* Explicity exclude from the core 
> dump,
> 100overrides the coredump filter 
> bits.  */
> 101 # define MADV_DODUMP▸ 17▸   /* Clear the MADV_DONTDUMP flag.  */
> 102 # define MADV_HWPOISON▸   100▸  /* Poison a page for testing.  */
> 103 #endif
> {noformat}
> However {{posix_madvise}} takes:
> {noformat}
> 107 # define POSIX_MADV_NORMAL▸ 0 /* No further special treatment.  */
> 108 # define POSIX_MADV_RANDOM▸ 1 /* Expect random page references.  
> */
> 109 # define POSIX_MADV_SEQUENTIAL▸ 2 /* Expect sequential page 
> references.  */
> 110 # define POSIX_MADV_WILLNEED▸   3 /* Will need these pages.  */
> 111 # define POSIX_MADV_DONTNEED▸   4 /* Don't need these pages.  */
> {noformat}
> Also {{posix_madvise}} and {{madvise}} can both be present on the same 
> system. However they do not have the same capability. That's why {{Explicity 
> exclude from the core dump, overrides the coredump filter bits}} 
> functionality isn't achievable through {{posix_madvise}}.
> Will post a PR momentarily.



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

[GitHub] trafficserver issue #1050: TS-4897: Unbound growth of number of memory maps ...

[PSUdaemon]

Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/1050
  
Patch for making the advice configurable.


---
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.
---

[jira] [Work logged] (TS-4897) Unbound growth of number of memory maps for traffic_server under SSL termination load when ssl_ticket_enabled=0

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 19:19
Start Date: 29/Sep/16 19:19
Worklog Time Spent: 10m 
  Work Description: Github user canselcik commented on the issue:

https://github.com/apache/trafficserver/pull/1050
  
A patch for ATS targeting some issues while running on 2.6.32 or a patch 
for making `MADV_DONTDUMP` configurable?


Issue Time Tracking
---

Worklog Id: (was: 29966)
Time Spent: 1h 40m  (was: 1.5h)

> Unbound growth of number of memory maps for traffic_server under SSL 
> termination load when ssl_ticket_enabled=0
> ---
>
> Key: TS-4897
> URL: https://issues.apache.org/jira/browse/TS-4897
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Can Selcik
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The number of {{\[anon\]}} memory regions mapped to the {{traffic_server}} 
> process displays unbound growth until the kernel thresholds are reached and 
> the process is terminated. 
> This happens when ATS is used to terminate SSL and {{ssl_ticket_enabled=0}} 
> in {{ssl_multicert.config}}.
> We've experienced this issue on our staging and production hosts and were 
> able to replicate it with the above configuration under high volume HTTPS 
> load. We didn't experience this with {{5.2.x}} and it will make sense why at 
> the end.
> While generating {{https}} traffic with {{siege}} or {{ab}}, the issue can be 
> observed with:
> {{watch "pmap $(pidof traffic_server) | wc -l"}}
> {{git bisect}} pointed us to: 
> Turns out a no-op {{ats_madvise}} hides the symptoms of the issue.
> Going in deeper, we realize that {{ssl_ticket_enabled}} option is relevant 
> because after enabling the {{ssl.session_cache}} tag, we see that ATS doesn't 
> manage its own session cache for SSL, it is done by the library instead. In 
> that case, the code path doing the problematic allocation within ATS doesn't 
> get executed often since OpenSSL takes care of the session tokens.
> But why does this happen? It happens because {{MADV_DONTDUMP}} is passed to 
> {{posix_madvise}} even though {{MADV_DONTDUMP}} is not a valid flag for 
> {{posix_madvise}} as it is not a drop-in replacement to {{madvise}}.
> Looking at {{}}:
> {noformat}
>  87 /* Advice to `madvise'.  */
>  88 #ifdef __USE_BSD
>  89 # define MADV_NORMAL▸ 0▸/* No further special treatment.  */
>  90 # define MADV_RANDOM▸ 1▸/* Expect random page references.  */
>  91 # define MADV_SEQUENTIAL  2▸/* Expect sequential page references. 
>  */
>  92 # define MADV_WILLNEED▸   3▸/* Will need these pages.  */
>  93 # define MADV_DONTNEED▸   4▸/* Don't need these pages.  */
>  94 # define MADV_REMOVE▸ 9▸/* Remove these pages and resources.  
> */
>  95 # define MADV_DONTFORK▸   10▸   /* Do not inherit across fork.  */
>  96 # define MADV_DOFORK▸ 11▸   /* Do inherit across fork.  */
>  97 # define MADV_MERGEABLE▸  12▸   /* KSM may merge identical pages.  */
>  98 # define MADV_UNMERGEABLE 13▸   /* KSM may not merge identical pages. 
>  */
>  99 # define MADV_DONTDUMP▸   16/* Explicity exclude from the core 
> dump,
> 100overrides the coredump filter 
> bits.  */
> 101 # define MADV_DODUMP▸ 17▸   /* Clear the MADV_DONTDUMP flag.  */
> 102 # define MADV_HWPOISON▸   100▸  /* Poison a page for testing.  */
> 103 #endif
> {noformat}
> However {{posix_madvise}} takes:
> {noformat}
> 107 # define POSIX_MADV_NORMAL▸ 0 /* No further special treatment.  */
> 108 # define POSIX_MADV_RANDOM▸ 1 /* Expect random page references.  
> */
> 109 # define POSIX_MADV_SEQUENTIAL▸ 2 /* Expect sequential page 
> references.  */
> 110 # define POSIX_MADV_WILLNEED▸   3 /* Will need these pages.  */
> 111 # define POSIX_MADV_DONTNEED▸   4 /* Don't need these pages.  */
> {noformat}
> Also {{posix_madvise}} and {{madvise}} can both be present on the same 
> system. However they do not have the same capability. That's why {{Explicity 
> exclude from the core dump, overrides the coredump filter bits}} 
> functionality isn't achievable through {{posix_madvise}}.
> Will post a PR momentarily.



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

[GitHub] trafficserver issue #1050: TS-4897: Unbound growth of number of memory maps ...

[canselcik]

Github user canselcik commented on the issue:

https://github.com/apache/trafficserver/pull/1050
  
A patch for ATS targeting some issues while running on 2.6.32 or a patch 
for making `MADV_DONTDUMP` configurable?


---
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.
---

[jira] [Work logged] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 18:59
Start Date: 29/Sep/16 18:59
Worklog Time Spent: 10m 
  Work Description: GitHub user brkishore opened a pull request:

https://github.com/apache/trafficserver/pull/1064

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook

globalHookHandler() [ts_lua.c] and 
ts_lua_http_cont_handler()[ts_lua_util.c] are modified to clear 
'client_response_hdrp' pointer when it enters SEND_RESPONSE_HDR hook.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brkishore/trafficserver TS-4911

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1064.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1064


commit 177d67c7df06622a9ee2eaaa837e31dde5298a76
Author: rb304g 
Date:   2016-09-29T18:42:56Z

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook.




Issue Time Tracking
---

Worklog Id: (was: 29965)
Time Spent: 10m
Remaining Estimate: 0h

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 

[GitHub] trafficserver pull request #1064: TS-4911: ts_lua plugin is modified to clea...

[brkishore]

GitHub user brkishore opened a pull request:

https://github.com/apache/trafficserver/pull/1064

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook

globalHookHandler() [ts_lua.c] and 
ts_lua_http_cont_handler()[ts_lua_util.c] are modified to clear 
'client_response_hdrp' pointer when it enters SEND_RESPONSE_HDR hook.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/brkishore/trafficserver TS-4911

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1064.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1064


commit 177d67c7df06622a9ee2eaaa837e31dde5298a76
Author: rb304g 
Date:   2016-09-29T18:42:56Z

TS-4911: ts_lua plugin is modified to clear 'client_response_hdrp' pointer 
when it enters SEND_RESPONSE_HDR hook.




---
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.
---

Jenkins build is back to normal : fedora_24-master » gcc,fedora_24,release #159

[jenkins]

See 

Build failed in Jenkins: fedora_24-master » gcc,fedora_24,release #158

[jenkins]

See 


--
[...truncated 175 lines...]
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
... 1 more
Build step 'Execute shell' marked build as failure
++ mv trafficserver-7.1.0/CONTRIBUTING.md trafficserver-7.1.0/CRUFT.txt 
trafficserver-7.1.0/INSTALL trafficserver-7.1.0/LAYOUT 
trafficserver-7.1.0/LICENSE trafficserver-7.1.0/Makefile.am 
trafficserver-7.1.0/Makefile.in trafficserver-7.1.0/NOTICE 
trafficserver-7.1.0/README trafficserver-7.1.0/README-EC2 
trafficserver-7.1.0/REVIEWERS trafficserver-7.1.0/STATUS 
trafficserver-7.1.0/Vagrantfile trafficserver-7.1.0/aclocal.m4 
trafficserver-7.1.0/build trafficserver-7.1.0/cmd 
trafficserver-7.1.0/config.layout trafficserver-7.1.0/configure 
trafficserver-7.1.0/configure.ac trafficserver-7.1.0/contrib 
trafficserver-7.1.0/doc trafficserver-7.1.0/emacs-style 
trafficserver-7.1.0/example trafficserver-7.1.0/iocore trafficserver-7.1.0/lib 
trafficserver-7.1.0/mgmt trafficserver-7.1.0/plugins trafficserver-7.1.0/proxy 
trafficserver-7.1.0/rc trafficserver-7.1.0/tools .
+ source /home/jenkins/bin/build.sh
++ enable_debug=
++ test fedora_24-master/compiler=gcc,label=fedora_24,type=release '!=' 
fedora_24-master/compiler=gcc,label=fedora_24,type=release
++ enable_ccache=--enable-ccache
++ test fedora_24-master/compiler=gcc,label=fedora_24,type=release '!=' 
fedora_24-master/compiler=gcc,label=fedora_24,type=release
++ enable_werror=--enable-werror
++ test 'Fedora Latest' '!=' 'Fedora Latest'
++ cd 

++ mkdir -p BUILDS
++ cd BUILDS
++ ../configure 
--prefix=
 --enable-experimental-plugins --enable-example-plugins --enable-test-tools 
--with-user=jenkins --enable-ccache --enable-werror
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '989' is supported by ustar format... yes
checking whether GID '665' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking for chosen layout... TrafficServer
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether to enable debugging... no
checking whether to code coverage... no
checking whether to enable -Werror... yes
checking whether to enable fast SDK APIs... no
checking whether to enable diags... yes
checking whether to enable regression tests... yes
checking whether to commit cov defects to remote host... localhost
checking whether to enable WCCP v2 support... no
checking whether to enable profiler... no
checking whether to enable eventfd()... yes
checking whether to use POSIX capabilities... auto
checking whether to use hwloc library... yes
checking whether to enable ccache... yes
checking whether to enable hardening of the executables... no
checking whether to enable SSLv3 config for origin connections... no
checking whether to enable TPROXY based transparency... auto
checking whether to enable experimental plugins... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBMEMCACHED... no
checking for LIBMAGICKCPP... no
checking whether to install example plugins... yes
checking whether to install testing tools... yes
checking whether to allow 32-bit builds... no
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc... gcc3
checking for c++... c++
checking whether we are using the GNU C++ compiler... yes
checking whether c++ accepts -g... yes
checking dependency style of c++... gcc3
checking whether cc 

[jira] [Updated] (TS-4912) Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4912:
--
Assignee: John Rushford

> Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy
> 
>
> Key: TS-4912
> URL: https://issues.apache.org/jira/browse/TS-4912
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Affects Versions: 6.2.0, 7.0.0
>Reporter: Leif Hedstrom
>Assignee: John Rushford
>Priority: Blocker
>  Labels: A
> Fix For: 7.1.0
>
>
> After upgrading to 6.2.x, we started noticing significant increases in 502 
> responses. We are using parent proxy heavily, so maybe this is related to 
> parent selection and/or handling?



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

[jira] [Updated] (TS-4912) Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4912:
--
Priority: Blocker  (was: Major)

> Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy
> 
>
> Key: TS-4912
> URL: https://issues.apache.org/jira/browse/TS-4912
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Affects Versions: 6.2.0, 7.0.0
>Reporter: Leif Hedstrom
>Priority: Blocker
>  Labels: A
> Fix For: 7.1.0
>
>
> After upgrading to 6.2.x, we started noticing significant increases in 502 
> responses. We are using parent proxy heavily, so maybe this is related to 
> parent selection and/or handling?



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

[jira] [Updated] (TS-4912) Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4912:
--
Labels: A  (was: )

> Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy
> 
>
> Key: TS-4912
> URL: https://issues.apache.org/jira/browse/TS-4912
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Affects Versions: 6.2.0, 7.0.0
>Reporter: Leif Hedstrom
>  Labels: A
> Fix For: 7.1.0
>
>
> After upgrading to 6.2.x, we started noticing significant increases in 502 
> responses. We are using parent proxy heavily, so maybe this is related to 
> parent selection and/or handling?



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

[jira] [Created] (TS-4912) Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4912:
-

 Summary: Increase in 502 when upgrading from 6.1 to 6.2 with 
parent proxy
 Key: TS-4912
 URL: https://issues.apache.org/jira/browse/TS-4912
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy
Reporter: Leif Hedstrom


After upgrading to 6.2.x, we started noticing significant increases in 502 
responses. We are using parent proxy heavily, so maybe this is related to 
parent selection and/or handling?



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

[jira] [Updated] (TS-4912) Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4912:
--
Fix Version/s: 7.1.0

> Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy
> 
>
> Key: TS-4912
> URL: https://issues.apache.org/jira/browse/TS-4912
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Affects Versions: 6.2.0, 7.0.0
>Reporter: Leif Hedstrom
>  Labels: A
> Fix For: 7.1.0
>
>
> After upgrading to 6.2.x, we started noticing significant increases in 502 
> responses. We are using parent proxy heavily, so maybe this is related to 
> parent selection and/or handling?



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

[jira] [Updated] (TS-4912) Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4912:
--
Affects Version/s: 7.0.0
   6.2.0

> Increase in 502 when upgrading from 6.1 to 6.2 with parent proxy
> 
>
> Key: TS-4912
> URL: https://issues.apache.org/jira/browse/TS-4912
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Affects Versions: 6.2.0, 7.0.0
>Reporter: Leif Hedstrom
>  Labels: A
> Fix For: 7.1.0
>
>
> After upgrading to 6.2.x, we started noticing significant increases in 502 
> responses. We are using parent proxy heavily, so maybe this is related to 
> parent selection and/or handling?



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

[jira] [Resolved] (TS-4903) EISCONN errors when using TCP Fast Open.

[James Peach (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-4903.
-
   Resolution: Fixed
Fix Version/s: 7.1.0

> EISCONN errors when using TCP Fast Open.
> 
>
> Key: TS-4903
> URL: https://issues.apache.org/jira/browse/TS-4903
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




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

[jira] [Work logged] (TS-4903) EISCONN errors when using TCP Fast Open.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Sep/16 15:16
Start Date: 29/Sep/16 15:16
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

https://github.com/apache/trafficserver/pull/1061


Issue Time Tracking
---

Worklog Id: (was: 29962)
Time Spent: 1h 20m  (was: 1h 10m)

> EISCONN errors when using TCP Fast Open.
> 
>
> Key: TS-4903
> URL: https://issues.apache.org/jira/browse/TS-4903
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




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

[GitHub] trafficserver pull request #1061: TS-4903: EISCONN errors when using TCP Fas...

[jpeach]

Github user jpeach closed the pull request at:

https://github.com/apache/trafficserver/pull/1061


---
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.
---

[jira] [Assigned] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Kit Chan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kit Chan reassigned TS-4911:


Assignee: Kit Chan

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the following code in ts_lua [ts_lua_client_response.c] plugin 
> causes the 

[jira] [Updated] (TS-4911) ts_lua restarts ATS when it is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem).

[Rajendra Kishore Bonumahanti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajendra Kishore Bonumahanti updated TS-4911:
-
Summary: ts_lua restarts ATS when it is used with collapsed_forwarding 
plugin and write lock error was encountered (thundering herd problem).   (was: 
ts_lua rebtarts ATS when it is used with collapsed_forwarding plugin and write 
lock error was encountered (thundering herd problem). )

> ts_lua restarts ATS when it is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem). 
> -
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Reporter: Rajendra Kishore Bonumahanti
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> 

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Rajendra Kishore Bonumahanti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajendra Kishore Bonumahanti updated TS-4911:
-
Fix Version/s: 7.1.0
   7.0.0
   6.2.1

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the following code in ts_lua 

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Rajendra Kishore Bonumahanti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajendra Kishore Bonumahanti updated TS-4911:
-
Affects Version/s: 7.1.0
   7.0.0
   6.2.1

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the following code 

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Rajendra Kishore Bonumahanti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajendra Kishore Bonumahanti updated TS-4911:
-
Summary: ATS restarts when ts_lua plugin is used with collapsed_forwarding 
plugin and write lock error was encountered (thundering herd problem)  (was: 
ts_lua restarts ATS when it is used with collapsed_forwarding plugin and write 
lock error was encountered (thundering herd problem). )

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Reporter: Rajendra Kishore Bonumahanti
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> 

[jira] [Created] (TS-4911) ts_lua rebtarts ATS when it is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem).

[Rajendra Kishore Bonumahanti (JIRA)]

Rajendra Kishore Bonumahanti created TS-4911:


 Summary: ts_lua rebtarts ATS when it is used with 
collapsed_forwarding plugin and write lock error was encountered (thundering 
herd problem). 
 Key: TS-4911
 URL: https://issues.apache.org/jira/browse/TS-4911
 Project: Traffic Server
  Issue Type: Bug
  Components: Lua, Plugins
Reporter: Rajendra Kishore Bonumahanti


ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
restarted due to “FATAL: InkAPI.cc:3800: failed assert 
`sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
was encountered (thundering herd problem). The ATS restart is due to 
ts.client_response.get_status() function call in TS_LUA_HOOK_SEND_RESPONSE_HDR 
hook function when re-direct is enabled on 502 error.

== error when ts_lua plugin is used with collapsed_forwarding plugin ==
map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
@pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
@plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5

test.lua:
===
function __init__()
   local FUNCTION = '__init__(): '
ts.debug(FUNCTION .. 'Entering..')

return 0
end

function responseHook()

local FUNCTION = 'responseHook(): '

ts.debug(FUNCTION .. 'Entering..')
local c_code = tostring(ts.client_response.get_status())
ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
if string.find(c_code, "^[45]") then
ts.debug(FUNCTION .. 'client response code is now set to 500')
ts.client_response.set_status(500)
end
return 0

end

function do_remap()
local FUNCTION = 'do_remap(): '

ts.debug(FUNCTION .. 'Entering..')
ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
return 0
end


The log…

[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
perform_cache_write_action CACE_DO_SERVE
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
is_redirect_required 1
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
Entering..
FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) == 
TS_SUCCESS`
traffic_server: using root directory '/opt/trafficserver'
validate_filter_args: "action=deny"
-
Filter "" status: allow_flag=false, src_ip_valid=false, 
in_ip_valid=false, internal=false active_queue_flag=0
standard methods=nonstandard methods=
src_ip_cnt=0
in_ip_cnt=0

URL Rewrite table with 3 entries
  Reverse Proxy is On
  Forward Mapping Table with 3 entries
 http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 0 
plugins]
 http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
running with  plugins]
 http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
running with 2 plugins]
  Reverse Mapping Table with 0 entries
  Permanent Redirect Mapping Table with 0 entries
  Temporary Redirect Mapping Table with 0 entries
  Forward Mapping With Recv Port Table with 0 entries
  Referer filter default redirect URL: "http://www.example.com/;
traffic_server: Aborted (Signal sent by tkill() 129399 99)
traffic_server - STACK TRACE:
/opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
/lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
/lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
/lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
/opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
/opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
/opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
/opt/trafficserver/bin/traffic_server[0x4c7973]
/opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
/opt/trafficserver/bin/traffic_server[0x5834e6]



It appears, the following code in ts_lua [ts_lua_client_response.c] plugin 
causes the sdk_sanity check failed.
#define TS_LUA_CHECK_CLIENT_RESPONSE_HDR(http_ctx)  
  \
  do {  
  \
if (!http_ctx->client_response_hdrp) {  
  \
  if (TSHttpTxnClientRespGet(http_ctx->txnp, 
_ctx->client_response_bufp, _ctx->client_response_hdrp) != \
  TS_SUCCESS) { 

[jira] [Updated] (TS-4910) We should get vc->mutex before do_io when the vc is acquired from session pool

[Oknet Xu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oknet Xu updated TS-4910:
-
Description: 
Component: ServerSessionPool
(I cound not found ServerSessionPool from JIRA)

source: proxy/http/HttpSessionManager.cc
{code}
309 // Now check to see if we have a connection in our shared connection 
pool
310 EThread *ethread   = this_ethread();
311 ProxyMutex *pool_mutex = (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) ?
312ethread->server_session_pool->mutex.get() :
313m_g_pool->mutex.get();
314 MUTEX_TRY_LOCK(lock, pool_mutex, ethread);
315 if (lock.is_locked()) {
316   if (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) {
317 retval = ethread->server_session_pool->acquireSession(ip, 
hostname_hash, match_style, sm, to_return);
318 Debug("http_ss", "[acquire session] thread pool search %s", 
to_return ? "successful" : "failed");
319   } else {
320 retval = m_g_pool->acquireSession(ip, hostname_hash, match_style, 
sm, to_return);
321 Debug("http_ss", "[acquire session] global pool search %s", 
to_return ? "successful" : "failed");
322 // At this point to_return has been removed from the pool. Do we 
need to move it
323 // to the same thread?
324 if (to_return) {
325   UnixNetVConnection *server_vc = dynamic_cast(to_return->get_netvc());
326   if (server_vc) {
327 UnixNetVConnection *new_vc = 
server_vc->migrateToCurrentThread(sm, ethread);
{code}

As the code above:

1. we get pool_mutex first
2. then acquire a vc from session pool
3. then migrate the vc to current thread without get vc->mutex

Depend on the comments, a SM only access VIO & VC that returned with callback.

The mutex of ServerSession may be different from server_vc while it is acquired 
from ServerSessionPool and attached to HttpSM.

HttpSM should get the server_vc->nh->mutex and server_vc->mutex first before 
call ServerSession->do_io(). Currently HttpSM does not.

The mutex create & usage list at below by timeline:

1. ClientVC is accepted from NetAccept with a new allocated mutex.
2. ClientSession is created and share the same mutex with ClientVC.
3. HttpSM is created and share the same mutex with ClientVC.
4. NetHandler get HttpSM->mutex and callback READ_READY to HttpSM by 
ClientVC->read.vio._cont.

{code}
ClientVC->nh->mutex is locked by EventSystem
HttpSM->mutex is locked by NetHandler
ClientVC->mutex is locked due share the same mutex with HttpSM

To access & modify a NetVC should get vc->nh->mutex and vc->mutex locked 
simultaneously.
{code}

5. Scenes1:
HttpSM create ServerVC with HttpSM->mutex by netProcessor.connect_re()
Then HttpSM create ServerSession with ServerVC and share the same mutex with 
HttpSM.

5. Scenes2:
HttpSM acquire a ServerSession from SessionPool and the ServerVC->thread is not 
current EThread.
The ServerSession->mutex is set to HttpSM->mutex while it is attached to HttpSM.
But the ServerVC->mutex is old one.

The first bug:
Before VC Migration merged:
- ServerSession->do_io() is called and directly call ServerVC->do_io() without 
get ServerVC->mutex first.

After VC Migration merged:
- Migrate ServerVC into current thread without get ServerVC->mutex first.

The second bug:
Before VC Migration merged:
- Any do_io() should lock vc->nh->mutex and vc->mutex simultaneously.


Suggestion:
1. Recall VC Migration
2. Re-design ServerSession

To re-design ServerSession:
1. Add NetHandler *servervc_nh to save ServerVC->nh while ServerVC is 
callbacked VC_EVENT_NET_OPEN to HttpSM.
2. For do_io(), check servervc_nh ==? get_NetHandler(this_ethread())
3a. equal, directly call ServerVC->do_io() and return ServerVC->VIO
3b. not equal, try lock servervc_nh->mutex and ServerVC->mutex
4a. if locked, directly call ServerVC->do_io() and return ServerVC->VIO
4b. if not, create a Cont and schedule it into 
servervc_nh->trigger_event->thread. The Cont will call ServerVC->do_io() later.


  was:
Component: ServerSessionPool
(I cound not found ServerSessionPool from JIRA)

source: proxy/http/HttpSessionManager.cc
{code}
309 // Now check to see if we have a connection in our shared connection 
pool
310 EThread *ethread   = this_ethread();
311 ProxyMutex *pool_mutex = (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) ?
312ethread->server_session_pool->mutex.get() :
313m_g_pool->mutex.get();
314 MUTEX_TRY_LOCK(lock, pool_mutex, ethread);
315 if (lock.is_locked()) {
316   if (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) {
317 retval = 

[jira] [Updated] (TS-4910) We should get vc->mutex before do_io when the vc is acquired from session pool

[Oknet Xu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oknet Xu updated TS-4910:
-
Description: 
Component: ServerSessionPool
(I cound not found ServerSessionPool from JIRA)

source: proxy/http/HttpSessionManager.cc
{code}
309 // Now check to see if we have a connection in our shared connection 
pool
310 EThread *ethread   = this_ethread();
311 ProxyMutex *pool_mutex = (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) ?
312ethread->server_session_pool->mutex.get() :
313m_g_pool->mutex.get();
314 MUTEX_TRY_LOCK(lock, pool_mutex, ethread);
315 if (lock.is_locked()) {
316   if (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) {
317 retval = ethread->server_session_pool->acquireSession(ip, 
hostname_hash, match_style, sm, to_return);
318 Debug("http_ss", "[acquire session] thread pool search %s", 
to_return ? "successful" : "failed");
319   } else {
320 retval = m_g_pool->acquireSession(ip, hostname_hash, match_style, 
sm, to_return);
321 Debug("http_ss", "[acquire session] global pool search %s", 
to_return ? "successful" : "failed");
322 // At this point to_return has been removed from the pool. Do we 
need to move it
323 // to the same thread?
324 if (to_return) {
325   UnixNetVConnection *server_vc = dynamic_cast(to_return->get_netvc());
326   if (server_vc) {
327 UnixNetVConnection *new_vc = 
server_vc->migrateToCurrentThread(sm, ethread);
{code}

As the code above:

1. we get pool_mutex first
2. then acquire a vc from session pool
3. then migrate the vc to current thread without get vc->mutex

Depend on the comments, a SM only access VIO & VC that returned with callback.

The mutex of ServerSession may be different from server_vc while it is acquired 
from ServerSessionPool and attached to HttpSM.

HttpSM should get the server_vc->nh->mutex and server_vc->mutex first before 
call ServerSession->do_io(). Currently HttpSM does not.

The mutex create & usage list at below by timeline:

1. ClientVC is accepted from NetAccept with a new allocated mutex.
2. ClientSession is created and share the same mutex with ClientVC.
3. HttpSM is created and share the same mutex with ClientVC.
4. NetHandler get HttpSM->mutex and callback READ_READY to HttpSM by 
ClientVC->read.vio._cont.

{code}
ClientVC->nh->mutex is locked by EventSystem
HttpSM->mutex is locked by NetHandler
ClientVC->mutex is locked due share the same mutex with HttpSM

To access & modify a NetVC should get vc->nh->mutex and vc->mutex locked 
simultaneously.
{code}

5. Scenes1:
HttpSM create ServerVC with HttpSM->mutex by netProcessor.connect_re()
Then HttpSM create ServerSession with ServerVC and share the same mutex with 
HttpSM.

5. Scenes2:
HttpSM acquire a ServerSession from SessionPool and the ServerVC->thread is not 
current EThread.
The ServerSession->mutex is set to HttpSM->mutex while it is attached to HttpSM.
But the ServerVC->mutex is old one.

The first bug:
Before VC Migration merged:
- ServerSession->do_io() is called and directly call ServerVC->do_io() without 
get ServerVC->mutex first.
After VC Migration merged:
- Migrate ServerVC into current thread without get ServerVC->mutex first.

The second bug:
Before VC Migration merged:
- Any do_io() should lock vc->nh->mutex and vc->mutex simultaneously.


Suggestion:
1. Recall VC Migration
2. Re-design ServerSession

To re-design ServerSession:
1. Add NetHandler *servervc_nh to save ServerVC->nh while ServerVC is 
callbacked VC_EVENT_NET_OPEN to HttpSM.
2. For do_io(), check servervc_nh ==? get_NetHandler(this_ethread())
3a. equal, directly call ServerVC->do_io() and return ServerVC->VIO
3b. not equal, try lock servervc_nh->mutex and ServerVC->mutex
4a. if locked, directly call ServerVC->do_io() and return ServerVC->VIO
4b. if not, create a Cont and schedule it into 
servervc_nh->trigger_event->thread. The Cont will call ServerVC->do_io() later.


  was:
Component: ServerSessionPool
(I cound not found ServerSessionPool from JIRA)

source: proxy/http/HttpSessionManager.cc
```
309 // Now check to see if we have a connection in our shared connection 
pool
310 EThread *ethread   = this_ethread();
311 ProxyMutex *pool_mutex = (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) ?
312ethread->server_session_pool->mutex.get() :
313m_g_pool->mutex.get();
314 MUTEX_TRY_LOCK(lock, pool_mutex, ethread);
315 if (lock.is_locked()) {
316   if (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) {
317 retval = 

[jira] [Created] (TS-4910) We should get vc->mutex before do_io when the vc is acquired from session pool

[Oknet Xu (JIRA)]

Oknet Xu created TS-4910:


 Summary: We should get vc->mutex before do_io when the vc is 
acquired from session pool
 Key: TS-4910
 URL: https://issues.apache.org/jira/browse/TS-4910
 Project: Traffic Server
  Issue Type: Bug
Reporter: Oknet Xu


Component: ServerSessionPool
(I cound not found ServerSessionPool from JIRA)

source: proxy/http/HttpSessionManager.cc
```
309 // Now check to see if we have a connection in our shared connection 
pool
310 EThread *ethread   = this_ethread();
311 ProxyMutex *pool_mutex = (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) ?
312ethread->server_session_pool->mutex.get() :
313m_g_pool->mutex.get();
314 MUTEX_TRY_LOCK(lock, pool_mutex, ethread);
315 if (lock.is_locked()) {
316   if (TS_SERVER_SESSION_SHARING_POOL_THREAD == 
sm->t_state.http_config_param->server_session_sharing_pool) {
317 retval = ethread->server_session_pool->acquireSession(ip, 
hostname_hash, match_style, sm, to_return);
318 Debug("http_ss", "[acquire session] thread pool search %s", 
to_return ? "successful" : "failed");
319   } else {
320 retval = m_g_pool->acquireSession(ip, hostname_hash, match_style, 
sm, to_return);
321 Debug("http_ss", "[acquire session] global pool search %s", 
to_return ? "successful" : "failed");
322 // At this point to_return has been removed from the pool. Do we 
need to move it
323 // to the same thread?
324 if (to_return) {
325   UnixNetVConnection *server_vc = dynamic_cast(to_return->get_netvc());
326   if (server_vc) {
327 UnixNetVConnection *new_vc = 
server_vc->migrateToCurrentThread(sm, ethread);
```

As the code above:

1. we get pool_mutex first
2. then acquire a vc from session pool
3. then migrate the vc to current thread without get vc->mutex

Depend on the comments, a SM only access VIO & VC that returned with callback.

The mutex of ServerSession may be different from server_vc while it is acquired 
from ServerSessionPool and attached to HttpSM.

HttpSM should get the server_vc->nh->mutex and server_vc->mutex first before 
call ServerSession->do_io(). Currently HttpSM does not.

ClientVC is accepted from NetAccept with a new allocated mutex.
Then ClientSession is created and share the same mutex with ClientVC.
Then HttpSM is created and share the same mutex with ClientVC.
Then NetHandler get HttpSM->mutex and callback READ_READY to HttpSM by 
ClientVC->read.vio._cont.
** ClientVC->nh->mutex is locked by EventSystem
** HttpSM->mutex is locked by NetHandler
** ClientVC->mutex is locked due share the same mutex with HttpSM

Scenes1:
HttpSM create ServerVC with HttpSM->mutex by netProcessor.connect_re()
Then HttpSM create ServerSession with ServerVC and share the same mutex with 
HttpSM.

Scenes2:
HttpSM acquire a ServerSession from SessionPool and the ServerVC->thread is not 
current EThread.
The ServerSession->mutex is set to HttpSM->mutex while it is attached to HttpSM.
But the ServerVC->mutex is old one.

The first bug:
Before VC Migration merged:
- ServerSession->do_io() is called and directly call ServerVC->do_io() without 
get ServerVC->mutex first.
After VC Migration merged:
- Migrate ServerVC into current thread without get ServerVC->mutex first.

The second bug:
Before VC Migration merged:
- Any do_io() should lock vc->nh->mutex and vc->mutex simultaneously.


Suggestion:
1. Recall VC Migration
2. Re-design ServerSession

To re-design ServerSession:
1. Add NetHandler *servervc_nh to save ServerVC->nh while ServerVC is 
callbacked VC_EVENT_NET_OPEN to HttpSM.
2. For do_io(), check servervc_nh ==? get_NetHandler(this_ethread())
3a. equal, directly call ServerVC->do_io() and return ServerVC->VIO
3b. not equal, try lock servervc_nh->mutex and ServerVC->mutex
4a. if locked, directly call ServerVC->do_io() and return ServerVC->VIO
4b. if not, create a Cont and schedule it into 
servervc_nh->trigger_event->thread. The Cont will call ServerVC->do_io() later.




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

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1062
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/796/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29961)
Time Spent: 40m  (was: 0.5h)

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver issue #1062: [TS-4908] Remove duplicated closing continuation.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1062
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/796/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1062
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/901/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29960)
Time Spent: 0.5h  (was: 20m)

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver issue #1062: [TS-4908] Remove duplicated closing continuation.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1062
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/901/ for details.
 



---
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.
---

[jira] [Work logged] (TS-4908) HTTP2Stream tries to close a continuation twice when a transaction is done

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1062
  
[approve ci]


Issue Time Tracking
---

Worklog Id: (was: 29959)
Time Spent: 20m  (was: 10m)

> HTTP2Stream tries to close a continuation twice when a transaction is done
> --
>
> Key: TS-4908
> URL: https://issues.apache.org/jira/browse/TS-4908
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: David Calavera
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This causes an assertion error when ATS is built in debug mode. Pull Request 
> coming.



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

[GitHub] trafficserver issue #1062: [TS-4908] Remove duplicated closing continuation.

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/1062
  
[approve ci]


---
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.
---