[jira] [Closed] (TS-4913) Crash with active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba closed TS-4913.
---
Resolution: Fixed

> Crash with active timeout
> -
>
> Key: TS-4913
> URL: https://issues.apache.org/jira/browse/TS-4913
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
>
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70859700 (LWP 5234)]
> 0x005c3c98 in ProxyClientTransaction::get_netvc (this=0x60ae0001c4e0) 
> at http/../ProxyClientTransaction.h:43
> 43  return (parent) ? parent->get_netvc() : NULL;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-106.el7_2.4.x86_64 libasan-4.8.3-9.el7.x86_64 
> libgcc-4.8.3-9.el7.x86_64 libstdc++-4.8.3-9.el7.x86_64 
> nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 pcre-8.32-15.el7_2.1.x86_64 
> tcl-8.5.13-4.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 
> zlib-1.2.7-13.el7.x86_64
> (gdb) bt
> #0  0x005c3c98 in ProxyClientTransaction::get_netvc 
> (this=0x60ae0001c4e0) at http/../ProxyClientTransaction.h:43
> #1  0x006b7376 in HttpSM::update_stats (this=0x7fffe69c71e0) at 
> HttpSM.cc:6967
> #2  0x006b5d6c in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6833
> #3  0x0068f7d2 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at HttpSM.cc:2671
> #4  0x00535fac in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at ../iocore/eventsystem/I_Continuation.h:153
> #5  0x00a1dc60 in read_signal_and_update (event=105, 
> vc=0x60aa00017d20) at UnixNetVConnection.cc:143
> #6  0x00a25c8b in UnixNetVConnection::mainEvent (this=0x60aa00017d20, 
> event=1, e=0x708588f0) at UnixNetVConnection.cc:1241
> #7  0x00535fac in Continuation::handleEvent (this=0x60aa00017d20, 
> event=1, data=0x708588f0) at ../iocore/eventsystem/I_Continuation.h:153
> #8  0x00a0df73 in NetHandler::_close_vc (this=0x716874e0, 
> vc=0x60aa00017d20, now=1475220689249441376, handle_event=@0x70858a50: 0,
> closed=@0x70858a10: 0, total_idle_time=@0x70858a90: 1, 
> total_idle_count=@0x70858ad0: 1) at UnixNet.cc:668
> #9  0x00a0ccd2 in NetHandler::manage_active_queue 
> (this=0x716874e0, ignore_queue_size=true) at UnixNet.cc:577
> #10 0x00a0f53c in InactivityCop::check_inactivity 
> (this=0x600c0001d2a0, event=2, e=0x608e6ca0) at UnixNet.cc:93
> #11 0x00535fac in Continuation::handleEvent (this=0x600c0001d2a0, 
> event=2, data=0x608e6ca0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c85 in EThread::process_event (this=0x71683800, 
> e=0x608e6ca0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a4d5 in EThread::execute (this=0x71683800) at 
> UnixEThread.cc:225
> #14 0x00a685d0 in spawn_thread_internal (a=0x600800015950) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p parent
> $1 = (ProxyClientSession *) 0x60ae0001c200
> (gdb) p parent->get_netvc()
> Cannot access memory at address 0x88
> {noformat}
> h3. Conditions
> - TS with debug and ASan
> - records.config
> {noformat}
> CONFIG proxy.config.http.transaction_active_timeout_in INT 1
> {noformat}
> - Using httpbin as origin server and remap to it
> - access to 'http://localhost:8080/httpbin/delay/2' via curl



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

[jira] [Commented] (TS-4913) Crash with active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba commented on TS-4913:
-

Sorry, this is not true. I'm seeing this issue with 7.0.x when 
{{proxy.config.http.slow.log.threshold}} is enabled.
So this is completely same as TS-4905.

> Crash with active timeout
> -
>
> Key: TS-4913
> URL: https://issues.apache.org/jira/browse/TS-4913
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
>
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70859700 (LWP 5234)]
> 0x005c3c98 in ProxyClientTransaction::get_netvc (this=0x60ae0001c4e0) 
> at http/../ProxyClientTransaction.h:43
> 43  return (parent) ? parent->get_netvc() : NULL;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-106.el7_2.4.x86_64 libasan-4.8.3-9.el7.x86_64 
> libgcc-4.8.3-9.el7.x86_64 libstdc++-4.8.3-9.el7.x86_64 
> nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 pcre-8.32-15.el7_2.1.x86_64 
> tcl-8.5.13-4.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 
> zlib-1.2.7-13.el7.x86_64
> (gdb) bt
> #0  0x005c3c98 in ProxyClientTransaction::get_netvc 
> (this=0x60ae0001c4e0) at http/../ProxyClientTransaction.h:43
> #1  0x006b7376 in HttpSM::update_stats (this=0x7fffe69c71e0) at 
> HttpSM.cc:6967
> #2  0x006b5d6c in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6833
> #3  0x0068f7d2 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at HttpSM.cc:2671
> #4  0x00535fac in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=105, data=0x60aa00017e48) at ../iocore/eventsystem/I_Continuation.h:153
> #5  0x00a1dc60 in read_signal_and_update (event=105, 
> vc=0x60aa00017d20) at UnixNetVConnection.cc:143
> #6  0x00a25c8b in UnixNetVConnection::mainEvent (this=0x60aa00017d20, 
> event=1, e=0x708588f0) at UnixNetVConnection.cc:1241
> #7  0x00535fac in Continuation::handleEvent (this=0x60aa00017d20, 
> event=1, data=0x708588f0) at ../iocore/eventsystem/I_Continuation.h:153
> #8  0x00a0df73 in NetHandler::_close_vc (this=0x716874e0, 
> vc=0x60aa00017d20, now=1475220689249441376, handle_event=@0x70858a50: 0,
> closed=@0x70858a10: 0, total_idle_time=@0x70858a90: 1, 
> total_idle_count=@0x70858ad0: 1) at UnixNet.cc:668
> #9  0x00a0ccd2 in NetHandler::manage_active_queue 
> (this=0x716874e0, ignore_queue_size=true) at UnixNet.cc:577
> #10 0x00a0f53c in InactivityCop::check_inactivity 
> (this=0x600c0001d2a0, event=2, e=0x608e6ca0) at UnixNet.cc:93
> #11 0x00535fac in Continuation::handleEvent (this=0x600c0001d2a0, 
> event=2, data=0x608e6ca0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c85 in EThread::process_event (this=0x71683800, 
> e=0x608e6ca0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a4d5 in EThread::execute (this=0x71683800) at 
> UnixEThread.cc:225
> #14 0x00a685d0 in spawn_thread_internal (a=0x600800015950) at 
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p parent
> $1 = (ProxyClientSession *) 0x60ae0001c200
> (gdb) p parent->get_netvc()
> Cannot access memory at address 0x88
> {noformat}
> h3. Conditions
> - TS with debug and ASan
> - records.config
> {noformat}
> CONFIG proxy.config.http.transaction_active_timeout_in INT 1
> {noformat}
> - Using httpbin as origin server and remap to it
> - access to 'http://localhost:8080/httpbin/delay/2' via curl



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

[GitHub] trafficserver pull request #1075: TS-4905: Set parent NULL after destroy() i...

[masaori335]

GitHub user masaori335 opened a pull request:

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

TS-4905: Set parent NULL after destroy() is called

[TS-4905](https://issues.apache.org/jira/browse/TS-4905)

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

$ git pull https://github.com/masaori335/trafficserver ts-4905

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

https://github.com/apache/trafficserver/pull/1075.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 #1075


commit 9b6cd5d444bba0b5476ef67f98eea504dd6fa596
Author: Masaori Koshiba 
Date:   2016-10-04T08:56:45Z

TS-4905: Set parent NULL after destroy() is called




---
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-4905) Crash when slow logging is enabled.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 09:40
Start Date: 04/Oct/16 09:40
Worklog Time Spent: 10m 
  Work Description: GitHub user masaori335 opened a pull request:

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

TS-4905: Set parent NULL after destroy() is called

[TS-4905](https://issues.apache.org/jira/browse/TS-4905)

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

$ git pull https://github.com/masaori335/trafficserver ts-4905

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

https://github.com/apache/trafficserver/pull/1075.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 #1075


commit 9b6cd5d444bba0b5476ef67f98eea504dd6fa596
Author: Masaori Koshiba 
Date:   2016-10-04T08:56:45Z

TS-4905: Set parent NULL after destroy() is called




Issue Time Tracking
---

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

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[GitHub] trafficserver issue #1075: TS-4905: Set parent NULL after destroy() is calle...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1075
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/924/ 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-4905) Crash when slow logging is enabled.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[GitHub] trafficserver issue #1075: TS-4905: Set parent NULL after destroy() is calle...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1075
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/818/ 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-4905) Crash when slow logging is enabled.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Commented] (TS-4905) Crash when slow logging is enabled.

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba commented on TS-4905:
-

I'm not seeing this issue with 6.2.0, but requesting the backport to 6.2.1.
Because it looks like the changes of TS-4507 made this and it is requested to 
backport to 6.2.1.

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Updated] (TS-4905) Crash when slow logging is enabled.

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4905:

Backport to Version: 6.2.1, 7.0.0  (was: 7.0.0)

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Assigned] (TS-4905) Crash when slow logging is enabled.

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba reassigned TS-4905:
---

Assignee: Masaori Koshiba

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Created] (TS-4927) Coverity issues in passthru example plugin

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4927:
-

 Summary: Coverity issues in passthru example plugin
 Key: TS-4927
 URL: https://issues.apache.org/jira/browse/TS-4927
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: Leif Hedstrom


{code}
*** CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
/example/passthru/passthru.cc: 214 in PassthruSessionEvent(tsapi_cont *, 
TSEvent, void *)()
208 
209   // Start the server end of the IO before we write any data.
210   sp->server.readio.read(sp->server.vconn, sp->contp);
211   sp->server.writeio.write(sp->server.vconn, sp->contp);
212 }
213 
   CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "sp->server.vconn" suggests that it may be null, but it has 
already been dereferenced on all paths leading to the check.
214 if (sp->server.vconn != nullptr) {
215   int64_t nbytes;
216 
217   nbytes = sp->client.readio.transfer_to(sp->server.writeio);
218   PassthruSessionDebug(sp, "proxied %" PRId64 " bytes from client 
vconn=%p to server vconn=%p", nbytes, sp->client.vconn,
219sp->server.vconn);

** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, tsapi_cont 
*)()



*** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, tsapi_cont 
*)()
91   void
92   write(TSVConn vconn, TSCont contp)
93   {
94 TSReleaseAssert(this->vio == NULL);
95 
96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
   CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
   Assignment "this->reader = TSIOBufferReaderAlloc(this->iobuf)" has a side 
effect.  This code will work differently in a non-debug build.
97 TSReleaseAssert((this->reader = TSIOBufferReaderAlloc(this->iobuf)));
98 
99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
100   }
101 
102   // Transfer data from this IO object to the target IO object.

** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, tsapi_cont 
*)()



*** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, tsapi_cont 
*)()
78   // Start a read operation.
79   void
80   read(TSVConn vconn, TSCont contp)
81   {
82 TSReleaseAssert(this->vio == NULL);
83 
   CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
   Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This code 
will work differently in a non-debug build.
84 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
85 TSReleaseAssert((this->reader = TSIOBufferReaderAlloc(this->iobuf)));
86 
87 this->vio = TSVConnRead(vconn, contp, this->iobuf, INT64_MAX);
88   }
89 

** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, tsapi_cont 
*)()



*** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, tsapi_cont 
*)()
90   // Start a write operation.
91   void
92   write(TSVConn vconn, TSCont contp)
93   {
94 TSReleaseAssert(this->vio == NULL);
95 
   CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
   Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This code 
will work differently in a non-debug build.
96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
97 TSReleaseAssert((this->reader = TSIOBufferReaderAlloc(this->iobuf)));
98 
99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
100   }
101 

** CID 1363655:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 85 in PassthruIO::read(tsapi_cont *, tsapi_cont 
*)()



*** CID 1363655:  Incorrect expression  (ASSERT_SIDE_EFFECT)
/example/passthru/passthru.cc: 85 in PassthruIO::read(tsapi_cont *, tsapi_cont 
*)()
79   void
80   read(TSVConn vconn, TSCont contp)
81   {
82 TSReleaseAssert(this->vio == NULL);
83 
84 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
   CID 1363655:  Incorrect expression  (ASSERT_SIDE_EFFECT)
   Assignm

[jira] [Updated] (TS-4927) Coverity issues in passthru example plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4927:
--
Assignee: James Peach

> Coverity issues in passthru example plugin
> --
>
> Key: TS-4927
> URL: https://issues.apache.org/jira/browse/TS-4927
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> {code}
> *** CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
> /example/passthru/passthru.cc: 214 in PassthruSessionEvent(tsapi_cont *, 
> TSEvent, void *)()
> 208 
> 209   // Start the server end of the IO before we write any data.
> 210   sp->server.readio.read(sp->server.vconn, sp->contp);
> 211   sp->server.writeio.write(sp->server.vconn, sp->contp);
> 212 }
> 213 
>CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
>Null-checking "sp->server.vconn" suggests that it may be null, but it has 
> already been dereferenced on all paths leading to the check.
> 214 if (sp->server.vconn != nullptr) {
> 215   int64_t nbytes;
> 216 
> 217   nbytes = sp->client.readio.transfer_to(sp->server.writeio);
> 218   PassthruSessionDebug(sp, "proxied %" PRId64 " bytes from client 
> vconn=%p to server vconn=%p", nbytes, sp->client.vconn,
> 219sp->server.vconn);
> ** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 91   void
> 92   write(TSVConn vconn, TSCont contp)
> 93   {
> 94 TSReleaseAssert(this->vio == NULL);
> 95 
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
>CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->reader = TSIOBufferReaderAlloc(this->iobuf)" has a side 
> effect.  This code will work differently in a non-debug build.
> 97 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 98 
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100   }
> 101 
> 102   // Transfer data from this IO object to the target IO object.
> ** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 78   // Start a read operation.
> 79   void
> 80   read(TSVConn vconn, TSCont contp)
> 81   {
> 82 TSReleaseAssert(this->vio == NULL);
> 83 
>CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This 
> code will work differently in a non-debug build.
> 84 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 85 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 86 
> 87 this->vio = TSVConnRead(vconn, contp, this->iobuf, INT64_MAX);
> 88   }
> 89 
> ** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 90   // Start a write operation.
> 91   void
> 92   write(TSVConn vconn, TSCont contp)
> 93   {
> 94 TSReleaseAssert(this->vio == NULL);
> 95 
>CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This 
> code will work differently in a non-debug build.
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 97 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 98 
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100   }
> 101 
> ** CID 1363655:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 85 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 

[jira] [Updated] (TS-4927) Coverity issues in passthru example plugin

[Leif Hedstrom (JIRA)]

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

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

> Coverity issues in passthru example plugin
> --
>
> Key: TS-4927
> URL: https://issues.apache.org/jira/browse/TS-4927
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 7.1.0
>
>
> {code}
> *** CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
> /example/passthru/passthru.cc: 214 in PassthruSessionEvent(tsapi_cont *, 
> TSEvent, void *)()
> 208 
> 209   // Start the server end of the IO before we write any data.
> 210   sp->server.readio.read(sp->server.vconn, sp->contp);
> 211   sp->server.writeio.write(sp->server.vconn, sp->contp);
> 212 }
> 213 
>CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
>Null-checking "sp->server.vconn" suggests that it may be null, but it has 
> already been dereferenced on all paths leading to the check.
> 214 if (sp->server.vconn != nullptr) {
> 215   int64_t nbytes;
> 216 
> 217   nbytes = sp->client.readio.transfer_to(sp->server.writeio);
> 218   PassthruSessionDebug(sp, "proxied %" PRId64 " bytes from client 
> vconn=%p to server vconn=%p", nbytes, sp->client.vconn,
> 219sp->server.vconn);
> ** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 91   void
> 92   write(TSVConn vconn, TSCont contp)
> 93   {
> 94 TSReleaseAssert(this->vio == NULL);
> 95 
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
>CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->reader = TSIOBufferReaderAlloc(this->iobuf)" has a side 
> effect.  This code will work differently in a non-debug build.
> 97 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 98 
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100   }
> 101 
> 102   // Transfer data from this IO object to the target IO object.
> ** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 78   // Start a read operation.
> 79   void
> 80   read(TSVConn vconn, TSCont contp)
> 81   {
> 82 TSReleaseAssert(this->vio == NULL);
> 83 
>CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This 
> code will work differently in a non-debug build.
> 84 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 85 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 86 
> 87 this->vio = TSVConnRead(vconn, contp, this->iobuf, INT64_MAX);
> 88   }
> 89 
> ** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 90   // Start a write operation.
> 91   void
> 92   write(TSVConn vconn, TSCont contp)
> 93   {
> 94 TSReleaseAssert(this->vio == NULL);
> 95 
>CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This 
> code will work differently in a non-debug build.
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 97 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 98 
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100   }
> 101 
> ** CID 1363655:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 85 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 13636

[jira] [Commented] (TS-4905) Crash when slow logging is enabled.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4905:
---

+1

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Updated] (TS-4905) Crash when slow logging is enabled.

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4905:
---
Priority: Blocker  (was: Major)

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Updated] (TS-4925) Manager puking EBADF everywhere

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4925:
---
Summary: Manager puking EBADF everywhere  (was: Manager puking EBADF 
everywhere.)

> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> [Oct  3 20:19:53.824] Manager {0x7f7b699a2800} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}



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

[jira] [Updated] (TS-4924) Protocol plugin performance penalty

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4924:
---
Summary: Protocol plugin performance penalty  (was: Protocol plugin 
performance penalty.)

> Protocol plugin performance penalty
> ---
>
> Key: TS-4924
> URL: https://issues.apache.org/jira/browse/TS-4924
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Performance, Plugins
>Reporter: James Peach
> Fix For: sometime
>
>
> It looks like protocol plugins take a significant performance penalty 
> compared to doing the same work in the code.
> *Configuratation:*
> {noformat}
> [root@fedora-23 ~]# cat /opt/ats/etc/trafficserver/remap.config
> map http://generator.jpeach.org/ http://127.0.0.1/ \
>   @plugin=generator.so
> [root@fedora-23 ~]# cat /opt/ats/etc/trafficserver/plugin.config
> passthru.so
> [root@fedora-23 ~]# tail /opt/ats/etc/trafficserver/records.config
> ...
> CONFIG config.plugin.passthru.server_ports STRING 9090
> {noformat}
> *http_load:*
> {noformat}
> http://generator.jpeach.org/cache/1024/1934f6c8-2cd6-46ea-9077-0532528fb1c9
> [vagrant@fedora-23 ~]$ http_load -proxy 127.0.0.1:8080 -parallel 50 -seconds 
> 20 -keep_alive 4 url.lst
> {noformat}
> We are using a generator URL of 1K that gets served from cache.



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

[jira] [Updated] (TS-4923) Add passthru example plugin

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4923:
---
Summary: Add passthru example plugin  (was: Add passthru example plugin.)

> Add passthru example plugin
> ---
>
> Key: TS-4923
> URL: https://issues.apache.org/jira/browse/TS-4923
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> Add a new example plugin {{passthru}}. This demonstrates various APIs as well 
> as performance issues encountered by protocol plugins.



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

[jira] [Updated] (TS-4921) Safe HTTP methods should be retryable

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4921:
---
Summary: Safe HTTP methods should be retryable  (was: Safe HTTP methods 
should be retryable.)

> Safe HTTP methods should be retryable
> -
>
> Key: TS-4921
> URL: https://issues.apache.org/jira/browse/TS-4921
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: James Peach
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>
> In {{HttpTransact::is_request_retryable}}, nothing seems to be retryable if 
> you have sent any bytes. Following the RFCs, the default behaviour should 
> allow safe (and also idempotent) method requests to be retried regardless of 
> thether bytes were sent.
> "safe" methods (https://tools.ietf.org/html/rfc7231#section-4.2.1): GET HEAD
> From conversations, it sounds like the ideal approach is to create a config 
> option (which is transaction overrideable) which allows you to define the 
> list of methods which are retryable (which wouldn't be limited to the 
> well-known methods inside ATS).



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

[jira] [Updated] (TS-4920) Consolidate accept socket options

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4920:
---
Summary: Consolidate accept socket options  (was: Consolidate accept socket 
options.)

> Consolidate accept socket options
> -
>
> Key: TS-4920
> URL: https://issues.apache.org/jira/browse/TS-4920
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We have an object {{AcceptOptions}} that contains the options to apply to 
> listening sockets, but in many places, the individual options are passed 
> around. Consolidate this so that we pass a {{AcceptOptions}} to provide 
> better guarantees that all listening sockets are created equal.



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

[jira] [Updated] (TS-4914) Duplicate headers are dropped on 304 responses

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4914:
---
Summary: Duplicate headers are dropped on 304 responses  (was: duplicate 
headers are dropped on 304 responses)

> Duplicate headers are dropped on 304 responses
> --
>
> Key: TS-4914
> URL: https://issues.apache.org/jira/browse/TS-4914
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Shinya Kawano
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When TrafficServer returns 304 Not Modified respons, duplicate headers are 
> dropped. TS returns only the first line of each headers.



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

[GitHub] trafficserver pull request #1075: TS-4905: Set parent NULL after destroy() i...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1075#discussion_r81791367
  
--- Diff: proxy/http/Http1ClientTransaction.cc ---
@@ -67,6 +67,7 @@ Http1ClientTransaction::transaction_done()
   // If the parent session is not in the closed state, the destroy will 
not occur.
   if (parent) {
 parent->destroy();
+parent = NULL;
--- End diff --

I don't think this is right, because ``destroy()`` might not destroy.


---
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-4905) Crash when slow logging is enabled.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 16:00
Start Date: 04/Oct/16 16:00
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1075#discussion_r81791367
  
--- Diff: proxy/http/Http1ClientTransaction.cc ---
@@ -67,6 +67,7 @@ Http1ClientTransaction::transaction_done()
   // If the parent session is not in the closed state, the destroy will 
not occur.
   if (parent) {
 parent->destroy();
+parent = NULL;
--- End diff --

I don't think this is right, because ``destroy()`` might not destroy.


Issue Time Tracking
---

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

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Updated] (TS-4891) ATS-7.0.x giving segmentation fault

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4891:
---
Backport to Version:   (was: 7.0.0)

> ATS-7.0.x giving segmentation fault
> ---
>
> Key: TS-4891
> URL: https://issues.apache.org/jira/browse/TS-4891
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Syeda Persia Aziz
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> The current 7.0.x branch is giving me segmentation fault as I run it. It 
> happens when trying to elevate_fopen Diags.log. It fails and shoots an 
> diags-error message which does not have any debug tag.
> The trace and info can be found here: 
> https://gist.github.com/persiaAziz/48a321a1c1913af1580261fa40d14df0



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

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

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4899:
---
Backport to Version:   (was: 7.0.0)

> 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.0.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] [Updated] (TS-4899) Http2ClientSession object leaks

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4899:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> 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.0.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] [Updated] (TS-4891) ATS-7.0.x giving segmentation fault

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4891:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> ATS-7.0.x giving segmentation fault
> ---
>
> Key: TS-4891
> URL: https://issues.apache.org/jira/browse/TS-4891
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 7.0.0
>Reporter: Syeda Persia Aziz
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> The current 7.0.x branch is giving me segmentation fault as I run it. It 
> happens when trying to elevate_fopen Diags.log. It fails and shoots an 
> diags-error message which does not have any debug tag.
> The trace and info can be found here: 
> https://gist.github.com/persiaAziz/48a321a1c1913af1580261fa40d14df0



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

Jenkins build is back to normal : centos_7-master » clang,centos_7,release #2037

[jenkins]

See 

[jira] [Created] (TS-4928) transactions should not destroy sessions

[James Peach (JIRA)]

James Peach created TS-4928:
---

 Summary: transactions should not destroy sessions
 Key: TS-4928
 URL: https://issues.apache.org/jira/browse/TS-4928
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: James Peach


In {{Http1ClientSession}} we find the following code:

{noformat}
void
Http1ClientTransaction::transaction_done()
{
  current_reader = NULL;
  // If the parent session is not in the closed state, the destroy will not 
occur.
  if (parent) {
parent->destroy();
  }
}
{noformat}

the model, as I understand it, is that sessions own transactions, so it is 
quite unexpected for the transaction to reach up an kill its parent. It is a 
very surprising side-effect of {{transaction_done}} and means that this can 
only be reliably used in the specific context of the calling code.

Additionally, why isn't the parent cleared in {{destroy()}}? If it must be 
NULL, we should have an assertion.



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

[GitHub] trafficserver pull request #1070: TS-4509 Add `outstanding_bytes` to VConnec...

[jacksontj]

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

https://github.com/apache/trafficserver/pull/1070#discussion_r81797531
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -5310,9 +5310,6 @@ HttpSM::handle_post_failure()
 tunnel.deallocate_buffers();
 tunnel.reset();
 // Server died
-vc_table.cleanup_entry(server_entry);
-server_entry  = NULL;
-server_session= NULL;
--- End diff --

We should get a new session-- but to do the "is retryable" check, I need 
access to the FD-- which is problematic if we release the session-- since it 
get cleared/closed etc. With these lines removed it seems that we aren't 
leaking sessions (from testing locally and in our staging env).


---
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-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 16:28
Start Date: 04/Oct/16 16:28
Worklog Time Spent: 10m 
  Work Description: Github user jacksontj commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1070#discussion_r81797531
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -5310,9 +5310,6 @@ HttpSM::handle_post_failure()
 tunnel.deallocate_buffers();
 tunnel.reset();
 // Server died
-vc_table.cleanup_entry(server_entry);
-server_entry  = NULL;
-server_session= NULL;
--- End diff --

We should get a new session-- but to do the "is retryable" check, I need 
access to the FD-- which is problematic if we release the session-- since it 
get cleared/closed etc. With these lines removed it seems that we aren't 
leaking sessions (from testing locally and in our staging env).


Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outli

[jira] [Assigned] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4929:
-

Assignee: Leif Hedstrom

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[jira] [Created] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4929:
-

 Summary: Should we avoid loading HostDB disk file is 
sync_frequency is '0' (disabled)
 Key: TS-4929
 URL: https://issues.apache.org/jira/browse/TS-4929
 Project: Traffic Server
  Issue Type: Improvement
  Components: HostDB
Reporter: Leif Hedstrom


This addresses two issues:

1) We get warnings trying to load a non-existent HostDB (since we don't sync 
it).

2) Worse, if someone has an old HostDB, that is no longer synced / updated, we 
load the old, possibly stale, data on every startup.

#2 seems inconsistent with the other changes to HostDB, where now the sync 
frequency =0 truly turns off disk syncing.



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

[jira] [Created] (TS-4930) Unfold request headers that are using continuations

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4930:
-

 Summary: Unfold request headers that are using continuations
 Key: TS-4930
 URL: https://issues.apache.org/jira/browse/TS-4930
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Reporter: Leif Hedstrom


In RFC 7230, we have

{code}
   Header fields that span multiple lines ("line folding") are
   deprecated.  (Section 3.2.4)
{code}

Our recommendation is to unfold these into a single line for now, possibly 
later add an option to make such request generate 40x errors.



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

[jira] [Updated] (TS-4930) Unfold request headers that are using obs continuations

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4930:
--
Summary: Unfold request headers that are using obs continuations  (was: 
Unfold request headers that are using continuations)

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[jira] [Updated] (TS-4930) Unfold request headers that are using obs continuations

[Leif Hedstrom (JIRA)]

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

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

Build failed in Jenkins: centos_7-master » gcc,centos_7,release #2037

[jenkins]

See 


--
[...truncated 19812 lines...]
0|0|114.61.13.0|114.61.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3945992723180975743|0|0|1|0
0|0|33.100.6.0|33.100.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6825087806830268671|0|0|1|0
0|0|83.94.9.0|83.94.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3346846807966173951|0|0|1|0
0|0|145.111.0.0|145.111.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4310273191177806975|0|0|1|0
RPRINT Congestion_CongestionDB: There are 1048576 records in the db
RPRINT Congestion_CongestionDB: After test [1] there are 1024 records in the db
RPRINT Congestion_CongestionDB: After test [2] there are 2816 records in the db
RPRINT Congestion_CongestionDB: After test [3] there are 1048576 records in the 
db
REGRESSION_RESULT Congestion_CongestionDB:  PASSED
REGRESSION TEST Congestion_FailHistory started
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 2612 , sum = 2612
RPRINT Congestion_FailHistory: bucket 1 => events 3974 , sum = 6586
RPRINT Congestion_FailHistory: bucket 2 => events 4015 , sum = 10601
RPRINT Congestion_FailHistory: bucket 3 => events 3855 , sum = 14456
RPRINT Congestion_FailHistory: bucket 4 => events 4029 , sum = 18485
RPRINT Congestion_FailHistory: bucket 5 => events 4023 , sum = 22508
RPRINT Congestion_FailHistory: bucket 6 => events 3828 , sum = 26336
RPRINT Congestion_FailHistory: bucket 7 => events 3855 , sum = 30191
RPRINT Congestion_FailHistory: bucket 8 => events 3914 , sum = 34105
RPRINT Congestion_FailHistory: bucket 9 => events 3864 , sum = 37969
RPRINT Congestion_FailHistory: bucket 10 => events 3926 , sum = 41895
RPRINT Congestion_FailHistory: bucket 11 => events 4018 , sum = 45913
RPRINT Congestion_FailHistory: bucket 12 => events 3957 , sum = 49870
RPRINT Congestion_FailHistory: bucket 13 => events 3935 , sum = 53805
RPRINT Congestion_FailHistory: bucket 14 => events 3959 , sum = 57764
RPRINT Congestion_FailHistory: bucket 15 => events 3869 , sum = 61633
RPRINT Congestion_FailHistory: bucket 16 => events 3903 , sum = 65536
Events: 65536, CurIndex: 0, LastEvent: 299, HistLen: 306, BinLen: 18, Start: 0
RPRINT Congestion_FailHistory: 233|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:03:53|0|299|65536|1|0
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 961 , sum = 961
RPRINT Congestion_FailHistory: bucket 1 => events 978 , sum = 1939
RPRINT Congestion_FailHistory: bucket 2 => events 602 , sum = 2541
RPRINT Congestion_FailHistory: bucket 3 => events 1011 , sum = 3552
RPRINT Congestion_FailHistory: bucket 4 => events 956 , sum = 4508
RPRINT Congestion_FailHistory: bucket 5 => events 1019 , sum = 5527
RPRINT Congestion_FailHistory: bucket 6 => events 992 , sum = 6519
RPRINT Congestion_FailHistory: bucket 7 => events 969 , sum = 7488
RPRINT Congestion_FailHistory: bucket 8 => events 1009 , sum = 8497
RPRINT Congestion_FailHistory: bucket 9 => events 950 , sum = 9447
RPRINT Congestion_FailHistory: bucket 10 => events 976 , sum = 10423
RPRINT Congestion_FailHistory: bucket 11 => events 974 , sum = 11397
RPRINT Congestion_FailHistory: bucket 12 => events 1007 , sum = 12404
RPRINT Congestion_FailHistory: bucket 13 => events 955 , sum = 13359
RPRINT Congestion_FailHistory: bucket 14 => events 998 , sum = 14357
RPRINT Congestion_FailHistory: bucket 15 => events 983 , sum = 15340
RPRINT Congestion_FailHistory: bucket 16 => events 1044 , sum = 16384
Events: 16384, CurIndex: 2, LastEvent: 2999, HistLen: 306, BinLen: 18, Start: 
2700
RPRINT Congestion_FailHistory: 2997|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:49:57|0|2999|16384|1|0
REGRESSION_RESULT Congestion_FailHistory:   PASSED
REGRESSION TEST Congestion_HashTable started
RPRINT Congestion_HashTable: adding data into the hash table 
...done
RPRINT Congestion_HashTable: 1048576 data added into the hash table
RPRINT Congestion_HashTable: verifying the 
content..done
RPRINT Congestion_HashTable: removing data..done
RPRINT Congestion_HashTable: 524287 data entries are removed
RPRINT Congestion_HashTable: verify the content 
again..done
RPRINT Congestion_HashTable: use iterator to list all the elements and delete 
half of themdone
RPRINT Congestion_HashTable: verify the content once again...done
RPRINT Congestion_HashTable: remove everything using iterator...done
REGRESSION_RESULT Congestion_HashTable: PASSED
REGRESSION TEST SDK_API_TSHttpConnectServerIntercept started
[SDK_API_TSHttpConnectServerIntercept] TSHttpConnect : [TestCase2] <> { 
ok }
[SDK_API_

[jira] [Assigned] (TS-4930) Unfold request headers that are using obs continuations

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4930:
-

Assignee: Leif Hedstrom

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[GitHub] trafficserver issue #1070: TS-4509: Add `outstanding_bytes` to VConnection

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/925/ 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 #1070: TS-4509: Add `outstanding_bytes` to VConnection

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/819/ 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-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[GitHub] trafficserver issue #1070: TS-4509: Add `outstanding_bytes` to VConnection

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/926/ 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-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[jira] [Work logged] (TS-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[GitHub] trafficserver issue #1070: TS-4509: Add `outstanding_bytes` to VConnection

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/820/ 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-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[jira] [Updated] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[Leif Hedstrom (JIRA)]

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

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

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[GitHub] trafficserver issue #1070: TS-4509: Add `outstanding_bytes` to VConnection

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/927/ 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 #1070: TS-4509: Add `outstanding_bytes` to VConnection

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1070
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/821/ 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-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[GitHub] trafficserver pull request #1076: TS-4929: No loading of HostDB disk file if...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4929: No loading of HostDB disk file if sync_frequency=0

This has two benefit (2) is most important I think:

1) We avoid warnings on startup about not being able to load the HostDB.

2) Since in 7.0.0, turning off syncing (sync_frequency=0) completely 
disables writing to HostDB, it's now possible to end up loading a potentially 
stale HostDB from a previous upgrade.


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

$ git pull https://github.com/zwoop/trafficserver TS-4929

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

https://github.com/apache/trafficserver/pull/1076.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 #1076


commit b89513b698ea72a09cb700a83ee4102413a708e8
Author: Leif Hedstrom 
Date:   2016-10-04T16:54:31Z

TS-4929: No loading of HostDB disk file if sync_frequency=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-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "&HttpSM::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



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

[jira] [Work logged] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 17:10
Start Date: 04/Oct/16 17:10
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4929: No loading of HostDB disk file if sync_frequency=0

This has two benefit (2) is most important I think:

1) We avoid warnings on startup about not being able to load the HostDB.

2) Since in 7.0.0, turning off syncing (sync_frequency=0) completely 
disables writing to HostDB, it's now possible to end up loading a potentially 
stale HostDB from a previous upgrade.


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

$ git pull https://github.com/zwoop/trafficserver TS-4929

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

https://github.com/apache/trafficserver/pull/1076.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 #1076


commit b89513b698ea72a09cb700a83ee4102413a708e8
Author: Leif Hedstrom 
Date:   2016-10-04T16:54:31Z

TS-4929: No loading of HostDB disk file if sync_frequency=0




Issue Time Tracking
---

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

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[GitHub] trafficserver issue #1076: TS-4929: No loading of HostDB disk file if sync_f...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1076
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/928/ 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-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[GitHub] trafficserver issue #1076: TS-4929: No loading of HostDB disk file if sync_f...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1076
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/822/ 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-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
> 
>
> Key: TS-4929
> URL: https://issues.apache.org/jira/browse/TS-4929
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This addresses two issues:
> 1) We get warnings trying to load a non-existent HostDB (since we don't sync 
> it).
> 2) Worse, if someone has an old HostDB, that is no longer synced / updated, 
> we load the old, possibly stale, data on every startup.
> #2 seems inconsistent with the other changes to HostDB, where now the sync 
> frequency =0 truly turns off disk syncing.



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

[jira] [Commented] (TS-4578) Skip HostDB lookup for all address literals

[David Ben Zakai (JIRA)]

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

David Ben Zakai commented on TS-4578:
-

Hi,

I'm thinking about taking this one by adding the following function:

bool
is_valid_ip_address(char *ip_address) {
// try ipv4
struct sockaddr_in sa;
int result = inet_pton(AF_INET, ipAddress, &(sa.sin_addr));

// Try ipv6
if (!result) {
result = inet_pton(AF_INET6, ipAddress, &(sa.sin_addr));
}

return result != 0;
}

I'd like to hear your input. Am I going in the right direction here? (if this 
function is ok with you guys where should I put it?)
Thanks!


> Skip HostDB lookup for all address literals
> ---
>
> Key: TS-4578
> URL: https://issues.apache.org/jira/browse/TS-4578
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, DNS
>Reporter: James Peach
>  Labels: newbie
> Fix For: sometime
>
>
> In {{HttpSM.cc}}:
> {code}
> if ((strncmp(t_state.dns_info.lookup_name, "127.0.0.1", 9) == 0 || 
> strncmp(t_state.dns_info.lookup_name, "::1", 3) == 0) &&
> ats_ip_pton(t_state.dns_info.lookup_name, t_state.host_db_info.ip()) 
> == 0) {
>   // If it's 127.0.0.1 or ::1 don't bother with hostdb
>   DebugSM("dns", "[HttpTransact::HandleRequest] Skipping DNS lookup for 
> %s because it's loopback",
>   t_state.dns_info.lookup_name);
>   t_state.dns_info.lookup_success = true;
>   call_transact_and_set_next_state(NULL);
>   break;
> {code}
> There's no reason to restrict address literals to loopback. It seems like we 
> should be able to do this for all address literals.



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

[jira] [Assigned] (TS-4578) Skip HostDB lookup for all address literals

[David Ben Zakai (JIRA)]

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

David Ben Zakai reassigned TS-4578:
---

Assignee: David Ben Zakai

> Skip HostDB lookup for all address literals
> ---
>
> Key: TS-4578
> URL: https://issues.apache.org/jira/browse/TS-4578
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, DNS
>Reporter: James Peach
>Assignee: David Ben Zakai
>  Labels: newbie
> Fix For: sometime
>
>
> In {{HttpSM.cc}}:
> {code}
> if ((strncmp(t_state.dns_info.lookup_name, "127.0.0.1", 9) == 0 || 
> strncmp(t_state.dns_info.lookup_name, "::1", 3) == 0) &&
> ats_ip_pton(t_state.dns_info.lookup_name, t_state.host_db_info.ip()) 
> == 0) {
>   // If it's 127.0.0.1 or ::1 don't bother with hostdb
>   DebugSM("dns", "[HttpTransact::HandleRequest] Skipping DNS lookup for 
> %s because it's loopback",
>   t_state.dns_info.lookup_name);
>   t_state.dns_info.lookup_success = true;
>   call_transact_and_set_next_state(NULL);
>   break;
> {code}
> There's no reason to restrict address literals to loopback. It seems like we 
> should be able to do this for all address literals.



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

[GitHub] trafficserver issue #712: TS-4523 - Add pause functionality to the Transform...

[ushachar]

Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
[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.
---

[jira] [Work logged] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 17:55
Start Date: 04/Oct/16 17:55
Worklog Time Spent: 10m 
  Work Description: Github user ushachar commented on the issue:

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


Issue Time Tracking
---

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

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[GitHub] trafficserver issue #712: TS-4523 - Add pause functionality to the Transform...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/929/ 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-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[GitHub] trafficserver issue #712: TS-4523 - Add pause functionality to the Transform...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/823/ 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-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[jira] [Created] (TS-4931) Add process limits to crash logs.

[James Peach (JIRA)]

James Peach created TS-4931:
---

 Summary: Add process limits to crash logs.
 Key: TS-4931
 URL: https://issues.apache.org/jira/browse/TS-4931
 Project: Traffic Server
  Issue Type: Improvement
  Components: Tools
Reporter: James Peach


Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
failures because we can get a reliable snapshot of any process limits in effect 
at the time.



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

[GitHub] trafficserver pull request #1077: TS-4931: Add process limits to crash logs.

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4931: Add process limits to crash logs.

Add /proc/$PID/limits to the crash log. This helps give context to
malloc failures because we can get a reliable snapshot of any process
limits in effect at the time.

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

$ git pull https://github.com/jpeach/trafficserver fix/4931

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

https://github.com/apache/trafficserver/pull/1077.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 #1077


commit 583c46f83d69e67abbc7179e80a32c341a970016
Author: James Peach 
Date:   2016-10-04T18:22:32Z

TS-4931: Add process limits to crash logs.

Add /proc/$PID/limits to the crash log. This helps give context to
malloc failures because we can get a reliable snapshot of any process
limits in effect at the time.




---
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-4931) Add process limits to crash logs.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 18:23
Start Date: 04/Oct/16 18:23
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-4931: Add process limits to crash logs.

Add /proc/$PID/limits to the crash log. This helps give context to
malloc failures because we can get a reliable snapshot of any process
limits in effect at the time.

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

$ git pull https://github.com/jpeach/trafficserver fix/4931

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

https://github.com/apache/trafficserver/pull/1077.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 #1077


commit 583c46f83d69e67abbc7179e80a32c341a970016
Author: James Peach 
Date:   2016-10-04T18:22:32Z

TS-4931: Add process limits to crash logs.

Add /proc/$PID/limits to the crash log. This helps give context to
malloc failures because we can get a reliable snapshot of any process
limits in effect at the time.




Issue Time Tracking
---

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

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

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

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1050
  
FWIW, I have some crash log on an 3.13 (ubuntu) kernel that have an 
extremely large number of entries in {{/proc/%PID/maps}}. Maybe this problem is 
not limited to 2.6 kernels?


---
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=30121&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30121
 ]

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 18:27
Start Date: 04/Oct/16 18:27
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1050
  
FWIW, I have some crash log on an 3.13 (ubuntu) kernel that have an 
extremely large number of entries in {{/proc/%PID/maps}}. Maybe this problem is 
not limited to 2.6 kernels?


Issue Time Tracking
---

Worklog Id: (was: 30121)
Time Spent: 2h 40m  (was: 2.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: 2h 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 #1077: TS-4931: Add process limits to crash logs.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1077
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/930/ 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-4931) Add process limits to crash logs.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

[GitHub] trafficserver issue #1077: TS-4931: Add process limits to crash logs.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1077
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/824/ 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-4931) Add process limits to crash logs.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

[jira] [Updated] (TS-4931) Add process limits to crash logs.

[James Peach (JIRA)]

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

James Peach updated TS-4931:

 Assignee: James Peach
 Priority: Minor  (was: Major)
Fix Version/s: 7.1.0

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

[GitHub] trafficserver pull request #1077: TS-4931: Add process limits to crash logs.

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4931) Add process limits to crash logs.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 18:59
Start Date: 04/Oct/16 18:59
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

[jira] [Resolved] (TS-4931) Add process limits to crash logs.

[James Peach (JIRA)]

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

James Peach resolved TS-4931.
-
Resolution: Fixed

> Add process limits to crash logs.
> -
>
> Key: TS-4931
> URL: https://issues.apache.org/jira/browse/TS-4931
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Tools
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add {{/proc/$PID/limits}} to the crash log. This helps give context to malloc 
> failures because we can get a reliable snapshot of any process limits in 
> effect at the time.



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

Jenkins build is back to normal : centos_7-master » gcc,centos_7,release #2038

[jenkins]

See 

[GitHub] trafficserver pull request #1078: TS-4930: Unfolds request headers that are ...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4930: Unfolds request headers that are using obs continuations

I also removed a file that is basically a duplication of another file, and 
this duplicated file is not used at all. This confused me as I was testing and 
updating the regression tests. Basically, that old test app is already 
incorporated into the regression tests.

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

$ git pull https://github.com/zwoop/trafficserver TS-4930

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

https://github.com/apache/trafficserver/pull/1078.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 #1078


commit d01e11b908b9368bf2e741d46626d989d9e76531
Author: Leif Hedstrom 
Date:   2016-10-04T17:22:05Z

TS-4930: Unfolds request headers that are using obs continuations

commit 544b343a37bda25a36ecb28f36a614b558ff43ab
Author: Leif Hedstrom 
Date:   2016-10-04T20:48:01Z

TS-4930: Removes an old test file, it duplicates HdrTest.cc




---
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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 20:58
Start Date: 04/Oct/16 20:58
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4930: Unfolds request headers that are using obs continuations

I also removed a file that is basically a duplication of another file, and 
this duplicated file is not used at all. This confused me as I was testing and 
updating the regression tests. Basically, that old test app is already 
incorporated into the regression tests.

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

$ git pull https://github.com/zwoop/trafficserver TS-4930

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

https://github.com/apache/trafficserver/pull/1078.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 #1078


commit d01e11b908b9368bf2e741d46626d989d9e76531
Author: Leif Hedstrom 
Date:   2016-10-04T17:22:05Z

TS-4930: Unfolds request headers that are using obs continuations

commit 544b343a37bda25a36ecb28f36a614b558ff43ab
Author: Leif Hedstrom 
Date:   2016-10-04T20:48:01Z

TS-4930: Removes an old test file, it duplicates HdrTest.cc




Issue Time Tracking
---

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[GitHub] trafficserver issue #1074: TS-4925: Manager pollMgmtProcessServer stuck with...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1074
  
@gtenev  Can you review this please?


---
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-4925) Manager puking EBADF everywhere

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 20:59
Start Date: 04/Oct/16 20:59
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1074
  
@gtenev  Can you review this please?


Issue Time Tracking
---

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

> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {noformat}
> [Oct  3 20:19:53.824] Manager {0x7f7b699a2800} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}



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

[GitHub] trafficserver issue #1074: TS-4925: Manager pollMgmtProcessServer stuck with...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1074
  
I'd imagine this is a backport candidate for at least 7.0.0, maybe 6.2.x ?


---
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-4925) Manager puking EBADF everywhere

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 21:00
Start Date: 04/Oct/16 21:00
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1074
  
I'd imagine this is a backport candidate for at least 7.0.0, maybe 6.2.x ?


Issue Time Tracking
---

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

> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
> [Oct  3 20:19:53.824] Manager {0x7f7b699a2800} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}



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

[GitHub] trafficserver issue #1078: TS-4930: Unfolds request headers that are using o...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1078
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/931/ 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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[GitHub] trafficserver issue #1078: TS-4930: Unfolds request headers that are using o...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1078
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/825/ 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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[jira] [Resolved] (TS-4681) traffic_top doc should explain output

[Jon Sime (JIRA)]

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

Jon Sime resolved TS-4681.
--
Resolution: Fixed

366399e Adds much more detail to the traffic_top docs, with explanations for 
all of the fields and references to the underlying TS statistics that are used.

> traffic_top doc should explain output
> -
>
> Key: TS-4681
> URL: https://issues.apache.org/jira/browse/TS-4681
> Project: Traffic Server
>  Issue Type: Task
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Jon Sime
> Fix For: Docs
>
>
> The current traffic_top page
> https://docs.trafficserver.apache.org/en/latest/appendices/command-line/traffic_top.en.html
> contains just the cli option (#seconds to refresh). It doesn't explain any of 
> the output.
> Would be nice to describe each of the line items. For instance, under the 
> Cache info column, what does Fresh mean (contrasting with Revalidate, Cold, 
> Changed)... and then what are the same in ms.
> Probably could start with a screen shot and describe the mini-sections (like 
> status Code 'histogram' in the upper right; followed by 'histogram' of file 
> sizes).



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

[GitHub] trafficserver pull request #1078: TS-4930: Unfolds request headers that are ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1078#discussion_r81870644
  
--- Diff: proxy/hdrs/HdrTest.cc ---
@@ -474,7 +474,9 @@ HdrTest::test_url()
 int
 HdrTest::test_mime()
 {
-  static const char mime[] = {
+  // This can not be a static string (any more) since we unfold the headers
+  // in place.
--- End diff --

So the contents now get modified? If so, we need to pass in non-const 
pointers.


---
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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 22:51
Start Date: 04/Oct/16 22:51
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1078#discussion_r81870634
  
--- Diff: proxy/hdrs/HdrTest.cc ---
@@ -522,6 +524,16 @@ HdrTest::test_mime()
 return (failures_to_status("test_mime", 1));
   }
 
+  // Test the (new) continuation line folding to be correct. This should 
replace the
+  // \r\n with two spaces (so a total of three between "part1" and 
"part2").
+  int length;
+  const char *continuation = hdr.value_get("continuation", 12, &length);
+
+  if ((13 != length) || strncmp(continuation, "part1   part2", 13) || 
strncmp(continuation + 5, "   ", 3)) {
--- End diff --

This will be easier to debug if you separate each condition into a separate 
failure.


Issue Time Tracking
---

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[jira] [Work logged] (TS-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 22:51
Start Date: 04/Oct/16 22:51
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1078#discussion_r81870774
  
--- Diff: proxy/hdrs/MIME.cc ---
@@ -2435,6 +2435,12 @@ mime_scanner_get(MIMEScanner *S, const char 
**raw_input_s, const char *raw_input
 case MIME_PARSE_AFTER:
   // After a LF. Might be the end or a continuation.
   if (ParseRules::is_ws(*raw_input_c)) {
+char *unfold = const_cast(raw_input_c - 1);
+
+*unfold-- = ' ';
+if (ParseRules::is_cr(*unfold)) {
+  *unfold = ' ';
--- End diff --

We can't accept const data if we do this.


Issue Time Tracking
---

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[GitHub] trafficserver pull request #1078: TS-4930: Unfolds request headers that are ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1078#discussion_r81870774
  
--- Diff: proxy/hdrs/MIME.cc ---
@@ -2435,6 +2435,12 @@ mime_scanner_get(MIMEScanner *S, const char 
**raw_input_s, const char *raw_input
 case MIME_PARSE_AFTER:
   // After a LF. Might be the end or a continuation.
   if (ParseRules::is_ws(*raw_input_c)) {
+char *unfold = const_cast(raw_input_c - 1);
+
+*unfold-- = ' ';
+if (ParseRules::is_cr(*unfold)) {
+  *unfold = ' ';
--- End diff --

We can't accept const data if we do this.


---
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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 22:51
Start Date: 04/Oct/16 22:51
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1078#discussion_r81870644
  
--- Diff: proxy/hdrs/HdrTest.cc ---
@@ -474,7 +474,9 @@ HdrTest::test_url()
 int
 HdrTest::test_mime()
 {
-  static const char mime[] = {
+  // This can not be a static string (any more) since we unfold the headers
+  // in place.
--- End diff --

So the contents now get modified? If so, we need to pass in non-const 
pointers.


Issue Time Tracking
---

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

> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated.  (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly 
> later add an option to make such request generate 40x errors.



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

[GitHub] trafficserver pull request #1078: TS-4930: Unfolds request headers that are ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1078#discussion_r81870634
  
--- Diff: proxy/hdrs/HdrTest.cc ---
@@ -522,6 +524,16 @@ HdrTest::test_mime()
 return (failures_to_status("test_mime", 1));
   }
 
+  // Test the (new) continuation line folding to be correct. This should 
replace the
+  // \r\n with two spaces (so a total of three between "part1" and 
"part2").
+  int length;
+  const char *continuation = hdr.value_get("continuation", 12, &length);
+
+  if ((13 != length) || strncmp(continuation, "part1   part2", 13) || 
strncmp(continuation + 5, "   ", 3)) {
--- End diff --

This will be easier to debug if you separate each condition into a separate 
failure.


---
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=30144&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30144
 ]

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

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

https://github.com/apache/trafficserver/pull/1052
  
@zwoop says it has been running 6 hours on docs without a crash.  Running 
in our production environment with other crashes (described in TS-4915), but no 
crashes directly related to HTTP/2 as far as I can tell.

Are we good with these changes?  This evening I'll start tidying up the 
commits.  I had been leaving in commented out code to make some of the code 
movements more obvious.


Issue Time Tracking
---

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

> 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: 4h 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.

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
@zwoop says it has been running 6 hours on docs without a crash.  Running 
in our production environment with other crashes (described in TS-4915), but no 
crashes directly related to HTTP/2 as far as I can tell.

Are we good with these changes?  This evening I'll start tidying up the 
commits.  I had been leaving in commented out code to make some of the code 
movements more obvious.


---
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 #1078: TS-4930: Unfolds request headers that are using o...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1078
  
Try build on freebsd again [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.
---