[jira] [Work logged] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[GitHub] trafficserver issue #1080: TS-4934: Remove invalid assert

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1080
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/936/ 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-4934) Assert in Http2Stream::do_io_close() when active timeout

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[GitHub] trafficserver issue #1080: TS-4934: Remove invalid assert

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1080
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/828/ 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-4934) Assert in Http2Stream::do_io_close() when active timeout

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[GitHub] trafficserver issue #1080: TS-4934: Remove invalid assert

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1080
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/934/ 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] [Updated] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4934:

Labels: 7.0.0  (was: )

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Updated] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4934:

Backport to Version: 7.0.0

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Updated] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4934:

Labels:   (was: 7.0.0)

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[jira] [Assigned] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba reassigned TS-4934:
---

Assignee: Masaori Koshiba

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

[GitHub] trafficserver pull request #1080: Remove invalid assert

[masaori335]

GitHub user masaori335 opened a pull request:

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

Remove invalid assert

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

The active timeout could be happen with any states of stream. So this 
assert doesn't make sense. 

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

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

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

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


commit d5e95097177bafd7a924183fd656cacec68e00ae
Author: Masaori Koshiba 
Date:   2016-10-05T05:17:20Z

Remove invalid assert




---
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-4578) Skip HostDB lookup for all address literals

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4578: Skip HostDB lookup for all address literals



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

$ git pull https://github.com/davidbz/trafficserver TS-4578

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

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


commit 47610146a60a698014b7c51dce149756ccf968f4
Author: David Ben Zakai 
Date:   2016-10-05T04:39:52Z

TS-4578: Skip HostDB lookup for all address literals




Issue Time Tracking
---

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

> 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
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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 pull request #1079: TS-4578: Skip HostDB lookup for all addres...

[davidbz]

GitHub user davidbz opened a pull request:

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

TS-4578: Skip HostDB lookup for all address literals



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

$ git pull https://github.com/davidbz/trafficserver TS-4578

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

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


commit 47610146a60a698014b7c51dce149756ccf968f4
Author: David Ben Zakai 
Date:   2016-10-05T04:39:52Z

TS-4578: Skip HostDB lookup for all address literals




---
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] [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=15547637#comment-15547637
 ] 

David Ben Zakai commented on TS-4578:
-

[~jamespeach] 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
>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)

[jira] [Updated] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4934:

Fix Version/s: 7.1.0

> Assert in Http2Stream::do_io_close() when active timeout
> 
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 7.1.0
>
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0  0x726e75f7 in raise () from /lib64/libc.so.6
> #1  0x726e8ce8 in abort () from /lib64/libc.so.6
> #2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
> failed assertion `%s`") at ink_error.cc:79
> #3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
> Http2Stream.cc:333
> #5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
> HttpSM.cc:227
> #7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
> HttpSM.cc:6756
> #8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler 
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}



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

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

[James Peach (JIRA)]

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

James Peach updated TS-4924:


Here is a motivating benchmark. I'm using the configuration above, which uses  
{{passthru.so}} as the protocol and {{generator.so}} as the origin server. I'm 
using a 1K cached URL, and {{wrk}} to generate load.

This is on a OS X 10.11, so real hardware but not that spiffy.

*Port 8080 (native ATS)*
{noformat}
$ wrk -s wrk.proxy  --connections 1 --threads 1 --duration 10 
http://127.0.0.1:8080 -- $url
Running 10s test @ http://127.0.0.1:8080
  1 threads and 1 connections
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency   137.66us   18.70us   1.32ms   91.55%
Req/Sec 7.09k82.87 7.27k71.29%
  71254 requests in 10.10s, 84.19MB read
Requests/sec:   7055.05
Transfer/sec:  8.34MB
{noformat}

*Port 9090 (passthru protocol plugin)*
{noformat}
$ wrk -s wrk.proxy  --connections 1 --threads 1 --duration 10 
http://127.0.0.1:9090 -- $url
Running 10s test @ http://127.0.0.1:9090
  1 threads and 1 connections
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency   495.67us  291.50us  13.83ms   99.84%
Req/Sec 1.79k   177.05 1.84k96.63%
  15970 requests in 10.03s, 18.79MB read
  Socket errors: connect 0, read 399, write 0, timeout 0
Requests/sec:   1591.89
Transfer/sec:  1.87MB
{noformat}

So we go from *7K RPS* to *1.5K RPS* simply by introducing a protocol plugin. 
It is possible that {{passthru.so}} is a pile of junk, but I would like to be 
convinced of that :)

> 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] [Created] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout

[Masaori Koshiba (JIRA)]

Masaori Koshiba created TS-4934:
---

 Summary: Assert in Http2Stream::do_io_close() when active timeout
 Key: TS-4934
 URL: https://issues.apache.org/jira/browse/TS-4934
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP/2
Reporter: Masaori Koshiba


{noformat}
Program received signal SIGABRT, Aborted.
0x726e75f7 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x726e75f7 in raise () from /lib64/libc.so.6
#1  0x726e8ce8 in abort () from /lib64/libc.so.6
#2  0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d: 
failed assertion `%s`") at ink_error.cc:79
#3  0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() == 
HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
at ink_assert.cc:37
#4  0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at 
Http2Stream.cc:333
#5  0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990, 
e=0x7fffe69c8990) at HttpSM.cc:216
#6  0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at 
HttpSM.cc:227
#7  0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at 
HttpSM.cc:6756
#8  0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0, event=106, 
data=0x7fffe6492e88) at HttpSM.cc:2671
#9  0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0, 
event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
#10 0x0075d136 in Http2Stream::main_event_handler (this=0x7fffe6492b40, 
event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
#11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40, 
event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
#12 0x00a69c41 in EThread::process_event (this=0x70c65800, 
e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
#13 0x00a6a491 in EThread::execute (this=0x70c65800) at 
UnixEThread.cc:225
#14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) 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 get_state()
$1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
{noformat}



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1074
  
@zwoop It is a race that happens when ``traffic_server`` keeps failing to 
start. 7.0 would be good but not sure we need to bother with 6.2


Issue Time Tracking
---

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

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

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1074
  
@zwoop It is a race that happens when ``traffic_server`` keeps failing to 
start. 7.0 would be good but not sure we need to bother with 6.2


---
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-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/947
  
@zwoop ping again :)


Issue Time Tracking
---

Worklog Id: (was: 30157)
Time Spent: 8h 20m  (was: 8h 10m)

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



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

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
@zwoop ping again :)


---
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] [Created] (TS-4933) Test connection reuse

[James Peach (JIRA)]

James Peach created TS-4933:
---

 Summary: Test connection reuse
 Key: TS-4933
 URL: https://issues.apache.org/jira/browse/TS-4933
 Project: Traffic Server
  Issue Type: Test
Reporter: James Peach


Following on from TS-3959, [~nickm] wrote an integration test for reusing keep 
alive connections that have been closed by the origin. Let's get this into a 
test harness and make sure the same scenario works for parent proxy scenarios.

https://github.com/GUI/TS-3959



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

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

[James Peach (JIRA)]

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

James Peach commented on TS-4578:
-

[~davidbz] take a look at {{ats_ip_pton}}.

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

[jira] [Created] (TS-4932) HTTP/2 tests.

[James Peach (JIRA)]

James Peach created TS-4932:
---

 Summary: HTTP/2 tests.
 Key: TS-4932
 URL: https://issues.apache.org/jira/browse/TS-4932
 Project: Traffic Server
  Issue Type: Test
Reporter: James Peach


We need both integration tests and unit tests to verify HTTP/2 functionality. 
There are a couple of unit tests, but nowhere near enough. There are no 
integration tests in CI or that are easy for developers to run.



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

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

Author: ASF GitHub Bot
Created on: 05/Oct/16 03:04
Start Date: 05/Oct/16 03:04
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/827/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30156)
Time Spent: 1h 40m  (was: 1.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: 1h 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 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/827/ 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=30155=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30155
 ]

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 30155)
Time Spent: 1.5h  (was: 1h 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: 1.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)

[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 *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/933/ 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] [Assigned] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[Gancho Tenev (JIRA)]

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

Gancho Tenev reassigned TS-4916:


Assignee: Gancho Tenev

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> --- count=3 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> . . . 
> --- count=5560 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> . . .
> {code}
> Currently I am working on finding out why the list in question got into this 
> “impossible” (broken) state and and eventually coming up with a fix.



--
This message was sent by Atlassian JIRA

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

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

Author: ASF GitHub Bot
Created on: 05/Oct/16 01:45
Start Date: 05/Oct/16 01:45
Worklog Time Spent: 10m 
  Work Description: Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Looks good to me  


Issue Time Tracking
---

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

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



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

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

[masaori335]

Github user masaori335 commented on the issue:

https://github.com/apache/trafficserver/pull/1052
  
Looks good to me 👍 


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

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

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

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

Yeah, I'm not 100% sure this is right or not. But from the backtrace, 
`destroy()` calls `free()`. In this case we need to set parent NULL.

```
#0  Http1ClientSession::free (this=0x60ae0001cc80) at 
Http1ClientSession.cc:100
#1  0x005c2386 in ProxyClientSession::handle_api_return 
(this=0x60ae0001cc80, event=6) at ProxyClientSession.cc:206
#2  0x005c1f25 in ProxyClientSession::do_api_callout 
(this=0x60ae0001cc80, id=TS_HTTP_SSN_CLOSE_HOOK) at ProxyClientSession.cc:177
#3  0x0065f787 in Http1ClientSession::destroy (this=0x60ae0001cc80) 
at Http1ClientSession.cc:93
#4  0x00664d20 in Http1ClientTransaction::transaction_done 
(this=0x60ae0001cf60) at Http1ClientTransaction.cc:69
```


Issue Time Tracking
---

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

> 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: 50m
>  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 pull request #1075: TS-4905: Set parent NULL after destroy() i...

[masaori335]

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

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

Yeah, I'm not 100% sure this is right or not. But from the backtrace, 
`destroy()` calls `free()`. In this case we need to set parent NULL.

```
#0  Http1ClientSession::free (this=0x60ae0001cc80) at 
Http1ClientSession.cc:100
#1  0x005c2386 in ProxyClientSession::handle_api_return 
(this=0x60ae0001cc80, event=6) at ProxyClientSession.cc:206
#2  0x005c1f25 in ProxyClientSession::do_api_callout 
(this=0x60ae0001cc80, id=TS_HTTP_SSN_CLOSE_HOOK) at ProxyClientSession.cc:177
#3  0x0065f787 in Http1ClientSession::destroy (this=0x60ae0001cc80) 
at Http1ClientSession.cc:93
#4  0x00664d20 in Http1ClientTransaction::transaction_done 
(this=0x60ae0001cf60) at Http1ClientTransaction.cc:69
```


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

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 23:19
Start Date: 04/Oct/16 23:19
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/826/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30150)
Time Spent: 1h 20m  (was: 1h 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: 1h 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/826/ 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=30149=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30149
 ]

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

Author: ASF GitHub Bot
Created on: 04/Oct/16 23:14
Start Date: 04/Oct/16 23:14
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/932/ for details.
 



Issue Time Tracking
---

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

> 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: 1h 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 #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/932/ 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=30147=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30147
 ]

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

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

https://github.com/apache/trafficserver/pull/1078
  
Try build on freebsd again [approve ci].


Issue Time Tracking
---

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

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

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

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

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

[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=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_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, );
+
+  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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4930?focusedWorklogId=30142=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, );
+
+  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)

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

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

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

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4925?focusedWorklogId=30134=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 #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=30133=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
  
@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-4930) Unfold request headers that are using obs continuations

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4930?focusedWorklogId=30132=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 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.
---

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

[jenkins]

See 

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

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

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

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

[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=30122=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
  
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-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=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 #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.
---

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

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

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

[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=30117=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
  
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=30116=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...

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

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

[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=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] [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=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
  
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=30113=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)

[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=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 
> "::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=30112=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 
> "::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/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.
---

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

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

[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=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 
> "::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=30107=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 
> "::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=30109=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 
> "::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=30108=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 
> "::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/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.
---

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

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 }