[jira] [Commented] (TS-3513) http2 core dump

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3513:


Another core:
{code}
(gdb) bt full
#0  0x7fffed265a72 in ?? ()
No symbol table info available.
#1  0x00521b88 in INKContInternal::handle_event (this=0x18a0240, 
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2  0x0050dbe0 in Continuation::handleEvent (this=0x18a0240, 
event=60017, data=0x7fff04e49980) at ../iocore/eventsystem/I_Continuation.h:145
No locals.
#3  0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017, 
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4  0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980, 
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = "state_api_callout"
#5  0x005f1e7f in HttpSM::do_api_callout_internal (this=0x7fff04e49980) 
at HttpSM.cc:4863
No locals.
#6  0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at 
HttpSM.cc:442
No locals.
#7  0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at 
HttpSM.cc:6876
__func__ = "set_next_state"
#8  0x005f8756 in HttpSM::call_transact_and_set_next_state 
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = "call_transact_and_set_next_state"
#9  0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at 
HttpSM.cc:6890
__func__ = "set_next_state"
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state 
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = "call_transact_and_set_next_state"
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at 
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980, 
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = "state_api_callout"
#13 0x005f1e7f in HttpSM::do_api_callout_internal (this=0x7fff04e49980) 
at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at 
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at 
HttpSM.cc:6876
__func__ = "set_next_state"
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state 
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = "call_transact_and_set_next_state"
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at 
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980, 
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = "state_api_callout"
{code}

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>  Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb

[jira] [Commented] (TS-3509) Access permissions for storage entries in cache.config changed

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3509:
---

So I'm not sure if/how/why this used to work. I've always had to use udev and 
change the ownership of the /dev devices for ATS to be able to use. I'm pretty 
sure that goes back to at least 4.x?

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 6.0.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Updated] (TS-3509) Access permissions for storage entries in cache.config changed

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3509:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 6.0.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Updated] (TS-3509) Access permissions for storage entries in cache.config changed

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3509:
--
Backport to Version:   (was: 5.3.0)

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 6.0.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Updated] (TS-3509) Access permissions for storage entries in cache.config changed

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3509:
--
Backport to Version: 5.3.0

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 6.0.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Updated] (TS-3511) Perl API seems to have a permission issue

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3511:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> Perl API seems to have a permission issue
> -
>
> Key: TS-3511
> URL: https://issues.apache.org/jira/browse/TS-3511
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 6.0.0
>
>
> Problems with the perl an grabbing stats:
> {code}
> [bcall@l1]$ sudo  /xxx/ats_gather # also tried -u nobody
> Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
> [bcall@l1]$ sudo traffic_line -m . | grep restrict
> proxy.config.admin.api.restricted 0  # tried with 0|1
> line 77:
>   my $cli = new Apache::TS::AdminClient(socket_path => 
> "$xxx/trafficserver/mgmtapisocket");
> {code}



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

[jira] [Updated] (TS-3510) header_rewrite is blocking building on raspberry pi

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3510:
--
Fix Version/s: sometime

> header_rewrite is blocking building on raspberry pi 
> 
>
> Key: TS-3510
> URL: https://issues.apache.org/jira/browse/TS-3510
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Plugins
>Reporter: Zhao Yongming
> Fix For: sometime
>
>
> ARM support is so good that we just have raspberrypi fail to build for 
> header_rewrite.
> {code}
> pi@raspberrypi ~/trafficserver/plugins/header_rewrite $ make -j 2
>   CXXconditions.lo
>   CXXheader_rewrite.lo
> {standard input}: Assembler messages:
> {standard input}:1221: Error: selected processor does not support ARM mode 
> `dmb'
>   CXXlulu.lo
>   CXXmatcher.lo
>   CXXoperator.lo
> Makefile:689: recipe for target 'conditions.lo' failed
> make: *** [conditions.lo] Error 1
> make: *** Waiting for unfinished jobs
> {code}



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

[jira] [Updated] (TS-3512) Add stats for http2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3512:
--
Fix Version/s: 6.0.0

> Add stats for http2
> ---
>
> Key: TS-3512
> URL: https://issues.apache.org/jira/browse/TS-3512
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
> Fix For: 6.0.0
>
>
> Add stats for:
> total number of connections
> total number of requests
> current number of connections
> maybe more...



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

[jira] [Commented] (TS-3513) http2 core dump

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3513:


Looks like a different core, but adding it here now:
{code}
(gdb) bt full
#0  0x00642a32 in Http2DynamicTable::set_dynamic_table_size 
(this=0x7ffe99b8b1e0, new_size=1) at HPACK.cc:219
last_name_len = 528
last_value_len = 32767
last_field = 0x7fffd4bc9550
old_size = 4096
#1  0x00643ab4 in update_dynamic_table_size (buf_start=0x7fffd4bc9550 
"!\202\005\251`Ѱ\231\377\303I\006=+\270\a\200\021\b\r\262ӡ\b\202'\376+4\220\005\265\303\361",
 ,
buf_end=0x7fffd4bc9638 "\016\225^", dynamic_table=...) at HPACK.cc:687
size = 1
len = 1
#2  0x00638fc7 in http2_parse_header_fragment (hdr=0x7ffe9a347868, 
iov=..., dynamic_table=..., cont=false) at HTTP2.cc:676
read_bytes = 0
field = 0x7ffd37259918
header = {_field = 0x7ffd37259918, _heap = 0x7ffd37259810, _mh = 
0x7ffd372598c8}
ftype = HPACK_FIELD_TABLESIZE_UPDATE
name_len = 32766
name = 0x7fffd4bc9530 " \246\274\324\377\177"
buf_end = 0x7fffd4bc9638 "\016\225^"
cursor = 0x7fffd4bc9550 
"!\202\005\251`Ѱ\231\377\303I\006=+\270\a\200\021\b\r\262ӡ\b\202'\376+4\220\005\265\303\361",
 
heap = 0x7ffd37259810
hh = 0x7ffd37259898
buf_start = 0x7fffd4bc9550 
"!\202\005\251`Ѱ\231\377\303I\006=+\270\a\200\021\b\r\262ӡ\b\202'\376+4\220\005\265\303\361",
 
#3  0x00641b5e in Http2Stream::decode_request_header 
(this=0x7ffe9a347840, iov=..., dynamic_table=..., cont=false) at 
Http2ConnectionState.h:139
No locals.
#4  0x0063e845 in rcv_headers_frame (cs=..., cstate=..., frame=...) at 
Http2ConnectionState.cc:222
read_len = 232
read_bytes = 232
cont = false
header_block_fragment = {iov_base = 0x7fffd4bc9550, iov_len = 232}
decoded_bytes = 2571080304
buf = 0x7fffd4bc9550 
"!\202\005\251`Ѱ\231\377\303I\006=+\270\a\200\021\b\r\262ӡ\b\202'\376+4\220\005\265\303\361",
 
params = {pad_length = 0 '\000', priority = {stream_dependency = 0, 
weight = 11 '\v'}}
__func__ = "rcv_headers_frame"
stream = 0x7ffe9a347840
nbytes = 237
id = 3
payload_length = 237
unpadded_length = 237
remaining_bytes = 0
#5  0x00640137 in Http2ConnectionState::main_event_handler 
(this=0x7ffe8efa1730, event=2253, edata=0x7fffd4bca7f0) at 
Http2ConnectionState.cc:643
frame = 0x7fffd4bca7f0
last_streamid = 3
error = 32767
__func__ = "main_event_handler"
{code}

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>  Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}



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

[jira] [Updated] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3500:
--
Fix Version/s: 6.0.0

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.0.0
>
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Updated] (TS-3502) TS API to get origin socket fd

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3502:
--
Labels: Review  (was: )

> TS API to get origin socket fd
> --
>
> Key: TS-3502
> URL: https://issues.apache.org/jira/browse/TS-3502
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>  Labels: Review
> Fix For: 6.0.0
>
>
> Currently, there's an API to get the client socket's fd 
> {{TSHttpTxnClientFdGet}} and {{TSHttpSsnClientFdGet}}. This API is used by 
> the {{tcpinfo}} plugin to get tcp stats for the client side socket. This jira 
> proposes to add the corresponding API for server socket fd. 
> {code}
> TSReturnCode TSHttpTxnServerFdGet(TSHttpTxn txnp, int *fdp);
> TSReturnCode TSHttpSsnServerFdGet(TSHttpSsn ssnp, int *fdp);
> {code}
> Note that the API will return {{TS_ERROR}} for a txn that returns a cached 
> response with the fd set to {{-1}}



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

[jira] [Updated] (TS-3506) ATS crashes with empty files in body-factory

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3506:
--
Labels: crash  (was: )

> ATS crashes with empty files in body-factory
> 
>
> Key: TS-3506
> URL: https://issues.apache.org/jira/browse/TS-3506
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 5.2.0, 5.2.1
>Reporter: Theo Hoogerheide
>  Labels: crash
> Fix For: 6.0.0
>
>
> When making the files empty in the body-factory, ATS crashes when sending for 
> instance a 404:
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [0x44])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
> /usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
> /usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
> /usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
> /usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
> /usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
> /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
> /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
> /usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
> /usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
> Segmentation fault (core dumped)
> {code}
> gdb:
> {code}
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/traffic_server -M --httpport 
> 8080:fd=8,8080:fd=9:ipv6'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  ink_atomic_increment (count=, mem= out>) at ink_atomic.h:89
> warning: Source file is more recent than executable.
> 89// ink_atomic_increment(ptr, count)
> {code}



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

[jira] [Updated] (TS-3502) TS API to get origin socket fd

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3502:
--
Fix Version/s: 6.0.0

> TS API to get origin socket fd
> --
>
> Key: TS-3502
> URL: https://issues.apache.org/jira/browse/TS-3502
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>  Labels: Review
> Fix For: 6.0.0
>
>
> Currently, there's an API to get the client socket's fd 
> {{TSHttpTxnClientFdGet}} and {{TSHttpSsnClientFdGet}}. This API is used by 
> the {{tcpinfo}} plugin to get tcp stats for the client side socket. This jira 
> proposes to add the corresponding API for server socket fd. 
> {code}
> TSReturnCode TSHttpTxnServerFdGet(TSHttpTxn txnp, int *fdp);
> TSReturnCode TSHttpSsnServerFdGet(TSHttpSsn ssnp, int *fdp);
> {code}
> Note that the API will return {{TS_ERROR}} for a txn that returns a cached 
> response with the fd set to {{-1}}



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

[jira] [Assigned] (TS-3506) ATS crashes with empty files in body-factory

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-3506:
-

Assignee: Leif Hedstrom

> ATS crashes with empty files in body-factory
> 
>
> Key: TS-3506
> URL: https://issues.apache.org/jira/browse/TS-3506
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 5.2.0, 5.2.1
>Reporter: Theo Hoogerheide
>Assignee: Leif Hedstrom
>  Labels: crash
> Fix For: 6.0.0
>
>
> When making the files empty in the body-factory, ATS crashes when sending for 
> instance a 404:
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [0x44])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
> /usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
> /usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
> /usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
> /usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
> /usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
> /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
> /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
> /usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
> /usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
> Segmentation fault (core dumped)
> {code}
> gdb:
> {code}
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/traffic_server -M --httpport 
> 8080:fd=8,8080:fd=9:ipv6'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  ink_atomic_increment (count=, mem= out>) at ink_atomic.h:89
> warning: Source file is more recent than executable.
> 89// ink_atomic_increment(ptr, count)
> {code}



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

[jira] [Updated] (TS-3506) ATS crashes with empty files in body-factory

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3506:
--
Fix Version/s: 6.0.0

> ATS crashes with empty files in body-factory
> 
>
> Key: TS-3506
> URL: https://issues.apache.org/jira/browse/TS-3506
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 5.2.0, 5.2.1
>Reporter: Theo Hoogerheide
>  Labels: crash
> Fix For: 6.0.0
>
>
> When making the files empty in the body-factory, ATS crashes when sending for 
> instance a 404:
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [0x44])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
> /usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
> /usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
> /usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
> /usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
> /usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
> /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
> /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
> /usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
> /usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
> Segmentation fault (core dumped)
> {code}
> gdb:
> {code}
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/traffic_server -M --httpport 
> 8080:fd=8,8080:fd=9:ipv6'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  ink_atomic_increment (count=, mem= out>) at ink_atomic.h:89
> warning: Source file is more recent than executable.
> 89// ink_atomic_increment(ptr, count)
> {code}



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

[jira] [Updated] (TS-3501) Support configuring nagle for client sockets using {{proxy.config.net.sock_option_flag_in}}

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3501:
--
Fix Version/s: 6.0.0

> Support configuring nagle for client sockets using 
> {{proxy.config.net.sock_option_flag_in}}
> ---
>
> Key: TS-3501
> URL: https://issues.apache.org/jira/browse/TS-3501
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.0.0
>
>
> https://docs.trafficserver.apache.org/en/latest/reference/configuration/records.config.en.html#proxy-config-net-sock-option-flag-in
>  describes a setting {{proxy.config.net.sock_option_flag_in}} to allow 
> enabling/disabling nagle algorithm on client (to ATS) sockets. However, 
> there's no code to handle the setting for the client socket and currently, 
> the client socket defaults to enabling Nagle. Opening this jira to make the 
> enhancement to allow configuring Nagle on the client socket.
> Note that the client socket option needs to be set in two places 
> (NetAccept::acceptFastEvent or the caller for when accept threads are 
> disabled and Server::accept when accept threads are enabled).



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

[jira] [Commented] (TS-3513) http2 core dump

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3513:
---

Should set the fix versions to 6.0.0, and then (maybe?) propose a back port to 
the RM.

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>  Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}



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

[jira] [Updated] (TS-3505) New plugin: cache promotion policies

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3505:
--
Fix Version/s: 6.0.0

> New plugin: cache promotion policies
> 
>
> Key: TS-3505
> URL: https://issues.apache.org/jira/browse/TS-3505
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.0.0
>
>
> This plugin will let you decide at cache write time if you really want to 
> allow the object to get into cache or not. Once in cache, it'll of course 
> continue to be served out of cache. The typical use case here is for a small 
> cache, where the tail-end content is huge. Instead of churning the disks, we 
> only allow to write objects to cache if they are "popular" enough.
> The first implementation only implements a very simple statistical policy, 
> ChancePolicy() which takes a percentage argument. So, you give it a 
> percentage, say 5%, which means there's a 5% chance that the response gets 
> written to cache. 95% of the time the requests will go to origin instead.
> Caveat: There's an unfortunate problem with the APIs I was hoping to use, so 
> right now it can only make the decision to write to cache or not in the 
> TS_HTTP_READ_RESPONSE_HDR_HOOK hook using TSHttpTxnServerRespNoStoreSet(txnp, 
> 1);



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

[jira] [Updated] (TS-3513) http2 core dump

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3513:
--
Labels: crash  (was: )

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>  Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}



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

[jira] [Updated] (TS-3513) http2 core dump

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3513:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>  Labels: crash
> Fix For: 6.0.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}



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

[jira] [Updated] (TS-3513) http2 core dump

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3513:
---
Fix Version/s: 5.3.0

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
> Fix For: 5.3.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}



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

[jira] [Updated] (TS-3513) http2 core dump

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3513:
---
Affects Version/s: 5.3.0

> http2 core dump
> ---
>
> Key: TS-3513
> URL: https://issues.apache.org/jira/browse/TS-3513
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0
>Reporter: Bryan Call
> Fix For: 5.3.0
>
>
> {code}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2ab5cbb3854d])traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
> /lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
> /lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
> /usr/bin/traffic_server[0x63e8b4]
> /usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x63b5fd]
> /usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
> /usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server[0x76dac7]
> /usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
> /usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
> /usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
> /usr/bin/traffic_server[0x78d43d]
> /lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
> /lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
> {code}



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

[jira] [Created] (TS-3513) http2 core dump

[Bryan Call (JIRA)]

Bryan Call created TS-3513:
--

 Summary: http2 core dump
 Key: TS-3513
 URL: https://issues.apache.org/jira/browse/TS-3513
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP/2
Reporter: Bryan Call


{code}
traffic_server: Segmentation fault (Invalid permissions for mapped object 
[0x2ab5cbb3854d])traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50abe2]
/lib64/libpthread.so.0(+0x3bb560f710)[0x2ab4b57c8710]
/lib64/libc.so.6(memmove+0x107)[0x3bb4e83907]
/usr/bin/traffic_server[0x63e8b4]
/usr/bin/traffic_server(_ZN20Http2ConnectionState18main_event_handlerEiPv+0x2eb)[0x640137]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
/usr/bin/traffic_server[0x63b5fd]
/usr/bin/traffic_server(_ZN18Http2ClientSession25state_complete_frame_readEiPv+0x28f)[0x63d379]
/usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
/usr/bin/traffic_server(_ZN18Http2ClientSession22state_start_frame_readEiPv+0x892)[0x63d0c0]
/usr/bin/traffic_server(_ZN18Http2ClientSession18main_event_handlerEiPv+0xfb)[0x63c26d]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
/usr/bin/traffic_server[0x76dac7]
/usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x20)[0x7703f4]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x75751c]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x628)[0x7676c8]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50da20]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x78de82]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x3dc)[0x78e38c]
/usr/bin/traffic_server[0x78d43d]
/lib64/libpthread.so.0(+0x3bb56079d1)[0x2ab4b57c09d1]
/lib64/libc.so.6(clone+0x6d)[0x3bb4ee88fd]
{code}



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

[jira] [Created] (TS-3512) Add stats for http2

[Bryan Call (JIRA)]

Bryan Call created TS-3512:
--

 Summary: Add stats for http2
 Key: TS-3512
 URL: https://issues.apache.org/jira/browse/TS-3512
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP/2
Reporter: Bryan Call


Add stats for:
total number of connections
total number of requests
current number of connections
maybe more...



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

[jira] [Updated] (TS-3511) Perl API seems to have a permission issue

[Bryan Call (JIRA)]

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

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

> Perl API seems to have a permission issue
> -
>
> Key: TS-3511
> URL: https://issues.apache.org/jira/browse/TS-3511
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> Problems with the perl an grabbing stats:
> {code}
> [bcall@l1]$ sudo  /xxx/ats_gather # also tried -u nobody
> Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
> [bcall@l1]$ sudo traffic_line -m . | grep restrict
> proxy.config.admin.api.restricted 0  # tried with 0|1
> line 77:
>   my $cli = new Apache::TS::AdminClient(socket_path => 
> "$xxx/trafficserver/mgmtapisocket");
> {code}



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

[jira] [Updated] (TS-3511) Perl API seems to have a permission issue

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3511:
---
Fix Version/s: 5.3.0

> Perl API seems to have a permission issue
> -
>
> Key: TS-3511
> URL: https://issues.apache.org/jira/browse/TS-3511
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
> Fix For: 5.3.0
>
>
> Problems with the perl an grabbing stats:
> {code}
> [bcall@l1]$ sudo  /xxx/ats_gather # also tried -u nobody
> Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
> [bcall@l1]$ sudo traffic_line -m . | grep restrict
> proxy.config.admin.api.restricted 0  # tried with 0|1
> line 77:
>   my $cli = new Apache::TS::AdminClient(socket_path => 
> "$xxx/trafficserver/mgmtapisocket");
> {code}



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

[jira] [Updated] (TS-3511) Perl API seems to have a permission issue

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3511:
---
Affects Version/s: 5.3.0

> Perl API seems to have a permission issue
> -
>
> Key: TS-3511
> URL: https://issues.apache.org/jira/browse/TS-3511
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Affects Versions: 5.3.0
>Reporter: Bryan Call
> Fix For: 5.3.0
>
>
> Problems with the perl an grabbing stats:
> {code}
> [bcall@l1]$ sudo  /xxx/ats_gather # also tried -u nobody
> Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
> [bcall@l1]$ sudo traffic_line -m . | grep restrict
> proxy.config.admin.api.restricted 0  # tried with 0|1
> line 77:
>   my $cli = new Apache::TS::AdminClient(socket_path => 
> "$xxx/trafficserver/mgmtapisocket");
> {code}



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

[jira] [Created] (TS-3511) Perl API seems to have a permission issue

[Bryan Call (JIRA)]

Bryan Call created TS-3511:
--

 Summary: Perl API seems to have a permission issue
 Key: TS-3511
 URL: https://issues.apache.org/jira/browse/TS-3511
 Project: Traffic Server
  Issue Type: Bug
  Components: Management API
Reporter: Bryan Call


Problems with the perl an grabbing stats:

{code}
[bcall@l1]$ sudo  /xxx/ats_gather # also tried -u nobody
Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
[bcall@l1]$ sudo traffic_line -m . | grep restrict
proxy.config.admin.api.restricted 0  # tried with 0|1

line 77:
  my $cli = new Apache::TS::AdminClient(socket_path => 
"$xxx/trafficserver/mgmtapisocket");
{code}



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

[jira] [Comment Edited] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3509 at 4/9/15 1:53 AM:


Confirmed with strace:
{code}
[bcall@l1]$ egrep 'cap|uid|dm-4' ~/out
getuid()= 0
setreuid(99, 99)= 0
getuid()= 99
geteuid()   = 99
capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 
CAP_DAC_OVERRIDE|CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 0}) = 0
open("/dev/dm-4", O_RDONLY) = -1 EACCES (Permission denied)
{code}


was (Author: bcall):
Confirmed with strace:
{code}
[bcall@l1]$ egrep 'setreuid|dm-4' ~/out
getuid()= 0
setreuid(99, 99)= 0
getuid()= 99
geteuid()   = 99
capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 
CAP_DAC_OVERRIDE|CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 0}) = 0
open("/dev/dm-4", O_RDONLY) = -1 EACCES (Permission denied)
{code}

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Comment Edited] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3509 at 4/9/15 1:53 AM:


It looks like it might be something going on with capabilities:

With 5.0.1:
{code}
[bcall@l2 ~]$ egrep 'cap|uid|dm-4' ~/out
geteuid()   = 0
geteuid()   = 0
getuid()= 0
setuid(99)  = 0
capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 
CAP_DAC_OVERRIDE|CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 0}) = 0
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
open("/dev/dm-4", O_RDONLY) = 12
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
open("/dev/dm-4", O_RDONLY) = 12
{code}


was (Author: bcall):
It looks like it might be something going on with capabilities:

With 5.0.1:
{code}
[bcall@l2 ~]$ egrep 'setuid|dm-4' ~/out
setuid(99)  = 0
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
open("/dev/dm-4", O_RDONLY) = 12
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
open("/dev/dm-4", O_RDONLY) = 12
open("/dev/dm-4", O_RDWR|O_DSYNC|O_DIRECT) = 376
[bcall@l2 ~]$ ll /dev/dm-4
brw-rw 1 root disk 253, 4 Apr  9 01:36 /dev/dm-4
{code}

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Comment Edited] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3509 at 4/9/15 1:52 AM:


Confirmed with strace:
{code}
[bcall@l1]$ egrep 'setreuid|dm-4' ~/out
getuid()= 0
setreuid(99, 99)= 0
getuid()= 99
geteuid()   = 99
capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 
CAP_DAC_OVERRIDE|CAP_NET_BIND_SERVICE|CAP_NET_ADMIN|CAP_IPC_LOCK, 0}) = 0
open("/dev/dm-4", O_RDONLY) = -1 EACCES (Permission denied)
{code}


was (Author: bcall):
Confirmed with strace:
{code}
[bcall@l1 trafficserver]$ egrep 'setreuid|dm-4' ~/out
setreuid(99, 99)= 0
open("/dev/dm-4", O_RDONLY) = -1 EACCES (Permission denied)
{code}

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Commented] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3509:


It looks like it might be something going on with capabilities:

With 5.0.1:
{code}
[bcall@l2 ~]$ egrep 'setuid|dm-4' ~/out
setuid(99)  = 0
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
open("/dev/dm-4", O_RDONLY) = 12
stat("/dev/dm-4", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 4), ...}) = 0
open("/dev/dm-4", O_RDONLY) = 12
open("/dev/dm-4", O_RDWR|O_DSYNC|O_DIRECT) = 376
[bcall@l2 ~]$ ll /dev/dm-4
brw-rw 1 root disk 253, 4 Apr  9 01:36 /dev/dm-4
{code}

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Created] (TS-3510) header_rewrite is blocking building on raspberry pi

[Zhao Yongming (JIRA)]

Zhao Yongming created TS-3510:
-

 Summary: header_rewrite is blocking building on raspberry pi 
 Key: TS-3510
 URL: https://issues.apache.org/jira/browse/TS-3510
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, Plugins
Reporter: Zhao Yongming


ARM support is so good that we just have raspberrypi fail to build for 
header_rewrite.

{code}
pi@raspberrypi ~/trafficserver/plugins/header_rewrite $ make -j 2
  CXXconditions.lo
  CXXheader_rewrite.lo
{standard input}: Assembler messages:
{standard input}:1221: Error: selected processor does not support ARM mode `dmb'
  CXXlulu.lo
  CXXmatcher.lo
  CXXoperator.lo
Makefile:689: recipe for target 'conditions.lo' failed
make: *** [conditions.lo] Error 1
make: *** Waiting for unfinished jobs
{code}



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

[jira] [Commented] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3500:
---

Perhaps, a combination of both patches might be better?

{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 0b5490d..1922195 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -4576,8 +4576,14 @@ TSHttpTxnPristineUrlGet(TSHttpTxn txnp, TSMBuffer *bufp, 
TSMLoc *url_loc)
 *(reinterpret_cast(bufp)) = hptr;
 *url_loc = (TSMLoc)sm->t_state.pristine_url.m_url_impl;
 
-if ((sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) && (*url_loc))
-  return TS_SUCCESS;
+if (sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) {
+  if (*url_loc == NULL) {
+*url_loc = (TSMLoc)hptr->m_http->u.req.m_url_impl;
+  }
+  if (*url_loc) {
+return TS_SUCCESS;
+  }
+}
   }
   return TS_ERROR;
 }
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 1648c18..a784368 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -758,6 +758,10 @@ HttpTransact::StartRemapRequest(State* s)
   if (s->api_skip_all_remapping) {
 Debug ("http_trans", "API request to skip remapping");
 
+s->hdr_info.client_request.set_url_target_from_host_field();
+//s->pristine_url.create(s->hdr_info.client_request.url_get()->m_heap);
+//s->pristine_url.copy(s->hdr_info.client_request.url_get());
+
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
   TRANSACT_RETURN(SM_ACTION_POST_REMAP_SKIP, 
s->post_remap_upgrade_return_point);
 }
{code}

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Commented] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3500:
---

Fully agree - fwiw, it's not entirely un-precedented though (like most things 
with ATS :=)). There are other Get() API that seem to also do things that are 
not very clean (e.g. {{TSHttpTxnCachedReqGet}}, {{TSHttpTxnCachedRespGet}}, 
{{TSHttpTxnCacheLookupUrlGet}}).

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Comment Edited] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3500 at 4/9/15 12:59 AM:


>From  within the API? That would be just as bad, in fact worse. IMO I should 
>be able to call this Getter as many times as I like and it shouldn't be an 
>expensive copy or anything . Changing the behavior such that the API has side 
>effects it didn't have before seems odd at best.


was (Author: zwoop):
>From my within the API? That would be just as bad, in fact worse. IMO I should 
>be able to call this Getter as many times as I like and it shouldn't be an 
>expensive copy or anything . Changing the behavior such that the API has side 
>effects it didn't have before seems odd at best.

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Comment Edited] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3500 at 4/9/15 12:58 AM:


>From my within the API? That would be just as bad, in fact worse. IMO I should 
>be able to call this Getter as many times as I like and it shouldn't be an 
>expensive copy or anything . Changing the behavior such that the API has side 
>effects it didn't have before seems odd at best.


was (Author: zwoop):
>From my within the API? That would be just as bad, in fact worse.

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Commented] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3500:
---

>From my within the API? That would be just as bad, in fact worse.

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Commented] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3500:
---

[~zwoop]: Agree, I am not comfortable with changing a Get() API to modify 
things as well. Instead, would it be better to simply copy *pristine_url* like 
the second patch above?

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Assigned] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda reassigned TS-3500:
-

Assignee: Sudheer Vinukonda

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Comment Edited] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda edited comment on TS-3500 at 4/9/15 12:33 AM:


Discussing on the IRC, [~zwoop] suggested to avoid (unnecessary!!) copy of the 
pristine url and simply make {{TSHttpTxnPristineUrlGet}} return 
client_request's url when pristine url is not set. Below's the proposed patch 
with this change:

{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 0b5490d..24fca80 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -4576,8 +4576,15 @@ TSHttpTxnPristineUrlGet(TSHttpTxn txnp, TSMBuffer *bufp, 
TSMLoc *url_loc)
 *(reinterpret_cast(bufp)) = hptr;
 *url_loc = (TSMLoc)sm->t_state.pristine_url.m_url_impl;
 
-if ((sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) && (*url_loc))
-  return TS_SUCCESS;
+if (sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) {
+  if (*url_loc == NULL) {
+hptr->set_url_target_from_host_field();
+*url_loc = (TSMLoc)hptr->m_http->u.req.m_url_impl;
+  }
+  if (*url_loc) {
+return TS_SUCCESS;
+  }
+}
   }
   return TS_ERROR;
 }
{code}

One concern with the above patch is that a Get() API could end up modifying 
stuff, which is potentially dangerous. 

Another (less efficient) approach is the below patch:

{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 1648c18..bf2a6b5 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -758,6 +758,10 @@ HttpTransact::StartRemapRequest(State* s)
   if (s->api_skip_all_remapping) {
 Debug ("http_trans", "API request to skip remapping");
 
+s->hdr_info.client_request.set_url_target_from_host_field();
+s->pristine_url.create(s->hdr_info.client_request.url_get()->m_heap);
+s->pristine_url.copy(s->hdr_info.client_request.url_get());
+
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
   TRANSACT_RETURN(SM_ACTION_POST_REMAP_SKIP, 
s->post_remap_upgrade_return_point);
 }
{code}


was (Author: sudheerv):
Discussing on the IRC, [~zwoop] suggested to avoid (unnecessary!!) copy of the 
pristine url and simply make {{TSHttpTxnPristineUrlGet}} return 
client_request's url when pristine url is not set. Below's the proposed patch 
with this change:

{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 0b5490d..24fca80 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -4576,8 +4576,15 @@ TSHttpTxnPristineUrlGet(TSHttpTxn txnp, TSMBuffer *bufp, 
TSMLoc *url_loc)
 *(reinterpret_cast(bufp)) = hptr;
 *url_loc = (TSMLoc)sm->t_state.pristine_url.m_url_impl;
 
-if ((sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) && (*url_loc))
-  return TS_SUCCESS;
+if (sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) {
+  if (*url_loc == NULL) {
+hptr->set_url_target_from_host_field();
+*url_loc = (TSMLoc)hptr->m_http->u.req.m_url_impl;
+  }
+  if (*url_loc) {
+return TS_SUCCESS;
+  }
+}
   }
   return TS_ERROR;
 }
{code}

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Commented] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3500:
---

I haven't lopoked at this thoroughly but is it really a goo idea to have side 
effects in a Get() API?

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Commented] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3509:


Confirmed with strace:
{code}
[bcall@l1 trafficserver]$ egrep 'setreuid|dm-4' ~/out
setreuid(99, 99)= 0
open("/dev/dm-4", O_RDONLY) = -1 EACCES (Permission denied)
{code}

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Created] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

Bryan Call created TS-3509:
--

 Summary: Access permissions for storage entries in cache.config 
changed
 Key: TS-3509
 URL: https://issues.apache.org/jira/browse/TS-3509
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Reporter: Bryan Call


It looks like 5.3.0 drops from root before opening up the disk storage now:

{code}
[Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
Store::read_config: "/dev/dm-4"
[Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
[Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
Store::read_config - could not initialize storage "/dev/dm-4" [unable to access 
file]

[bcall@l1 ~]$ ll /dev/dm-4
brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
[bcall@l1 ~]$ chmod 666 /dev/dm-4
{code}



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

[jira] [Updated] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3509:
---
Affects Version/s: 5.3.0

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Updated] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

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

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Priority: Blocker
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Updated] (TS-3509) Access permissions for storage entries in cache.config changed

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3509:
---
Fix Version/s: 5.3.0

> Access permissions for storage entries in cache.config changed
> --
>
> Key: TS-3509
> URL: https://issues.apache.org/jira/browse/TS-3509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Bryan Call
> Fix For: 5.3.0
>
>
> It looks like 5.3.0 drops from root before opening up the disk storage now:
> {code}
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config: "/dev/dm-4"
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - ns = new Span; ns->init("/dev/dm-4",-1), forced volume=-1
> [Apr  8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init) 
> Store::read_config - could not initialize storage "/dev/dm-4" [unable to 
> access file]
> [bcall@l1 ~]$ ll /dev/dm-4
> brw-rw 1 root disk 253, 4 Apr  8 23:52 /dev/dm-4
> [bcall@l1 ~]$ chmod 666 /dev/dm-4
> {code}



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

[jira] [Commented] (TS-3500) pristine url is not populated when TSSkipRemappingSet is enabled

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3500:
---

Discussing on the IRC, [~zwoop] suggested to avoid (unnecessary!!) copy of the 
pristine url and simply make {{TSHttpTxnPristineUrlGet}} return 
client_request's url when pristine url is not set. Below's the proposed patch 
with this change:

{code}
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
index 0b5490d..24fca80 100644
--- a/proxy/InkAPI.cc
+++ b/proxy/InkAPI.cc
@@ -4576,8 +4576,15 @@ TSHttpTxnPristineUrlGet(TSHttpTxn txnp, TSMBuffer *bufp, 
TSMLoc *url_loc)
 *(reinterpret_cast(bufp)) = hptr;
 *url_loc = (TSMLoc)sm->t_state.pristine_url.m_url_impl;
 
-if ((sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) && (*url_loc))
-  return TS_SUCCESS;
+if (sdk_sanity_check_mbuffer(*bufp) == TS_SUCCESS) {
+  if (*url_loc == NULL) {
+hptr->set_url_target_from_host_field();
+*url_loc = (TSMLoc)hptr->m_http->u.req.m_url_impl;
+  }
+  if (*url_loc) {
+return TS_SUCCESS;
+  }
+}
   }
   return TS_ERROR;
 }
{code}

> pristine url is not populated when TSSkipRemappingSet is enabled
> 
>
> Key: TS-3500
> URL: https://issues.apache.org/jira/browse/TS-3500
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sudheer Vinukonda
>
> pristine url is not populated when TSSkipRemappingSet is enabled



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

[jira] [Commented] (TS-3508) use accept4 on linux systems where available to reduce system calls

[James Peach (JIRA)]

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

James Peach commented on TS-3508:
-

You can also set {{CLOEXEC}} on it.

> use accept4 on linux systems where available to reduce system calls
> ---
>
> Key: TS-3508
> URL: https://issues.apache.org/jira/browse/TS-3508
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.0.0
>
>
> The accept4() syscall can set flags on the accepted socket.



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

[jira] [Comment Edited] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3487 at 4/8/15 9:41 PM:


Here is a debug of a long lived GET request where the origin sends a few bytes 
every 10 seconds.  The inactivity timeout is cleared because it is a GET and 
then reset to the default because there is none set by inactivity cop.  When 
data gets sent from the origin through the proxy, write_disable is called it 
again clears inactivity for the client and then the default get set again by 
inactivity cop.

Debug output:
{code}
[Apr  8 14:27:54.670] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 0, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) 
UnixNetVConnection::remove_from_keep_alive_lru NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=1200, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set active 
timeout=9000, NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=300, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Cancel 
inactive timeout for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) ::open: setsockopt() TCP_NODELAY on socket
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=50, for NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set active 
timeout=0, NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) read_disable updating inactivity_at 0, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 50, 
NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 50, 
NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=250, for NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=300, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 300, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG:  (socket) write_disable updating inactivity_at 0, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:55.055] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528475055227000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:55.055] Server {0x7fff73072300} DEBUG:  (inactivity_cop) vc: 0x7fbe7b8b3d40 inactivity timeout not 
set, setting a default of 86400
[Apr  8 14:27:55.055] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=864000, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:56.053] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
142852847605385 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:56.053] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
142852847605385 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:27:57.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528477055982000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:57.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528477055982000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:27:58.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528478059062000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:58.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528478059062000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:27:59.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528479056493000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:59.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528479056493000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:28:00.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528480059704000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:28:00.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528480059704000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:28:01.058] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528481058265000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:28:01.058] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b

[jira] [Commented] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3487:


Here is a debug of a long lived GET request where the origin send a few bytes 
every 10 seconds.  The inactivity timeout is cleared because it is a GET and 
then reset to the default because there is none set by inactivity cop.  When 
data gets sent from the origin through the proxy when write_disable is called 
it again clears inactivity for the client and then the default get set again by 
inactivity cop.

Debug output:
{code}
[Apr  8 14:27:54.670] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 0, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) 
UnixNetVConnection::remove_from_keep_alive_lru NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=1200, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set active 
timeout=9000, NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=300, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Cancel 
inactive timeout for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) ::open: setsockopt() TCP_NODELAY on socket
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=50, for NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG: 
 (socket) Set active 
timeout=0, NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) read_disable updating inactivity_at 0, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.671] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 50, 
NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 50, 
NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=250, for NetVC=0x7fbe7b8b3a80
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=300, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG:  (socket) net_activity updating inactivity 300, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:54.673] Server {0x7fff73072300} DEBUG:  (socket) write_disable updating inactivity_at 0, 
NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:55.055] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528475055227000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:55.055] Server {0x7fff73072300} DEBUG:  (inactivity_cop) vc: 0x7fbe7b8b3d40 inactivity timeout not 
set, setting a default of 86400
[Apr  8 14:27:55.055] Server {0x7fff73072300} DEBUG: 
 (socket) Set inactive 
timeout=864000, for NetVC=0x7fbe7b8b3d40
[Apr  8 14:27:56.053] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
142852847605385 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:56.053] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
142852847605385 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:27:57.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528477055982000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:57.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528477055982000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:27:58.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528478059062000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:58.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528478059062000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:27:59.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528479056493000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:27:59.056] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528479056493000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:28:00.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528480059704000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:28:00.059] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528480059704000 timeout at: 1428614875 timeout in: 86400
[Apr  8 14:28:01.058] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3a80 now: 
1428528481058265000 timeout at: 1428528499 timeout in: 25
[Apr  8 14:28:01.058] Server {0x7fff73072300} DEBUG:  (inactivity_cop_verbose) vc: 0x7fbe7b8b3d40 now: 
1428528481058265000 timeout at:

[jira] [Commented] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3487:
---

Agree with [~bcall] - yes, the transaction level inactivity timers will be 
cancelled at the point before sending origin request for requests without body 
and after the 1st byte from origin is received for requests with body (but, 
there's always the default inactivity timer set by the inactivity cop that 
takes over).

The problem with the attached patch is that, it doesn't let to override 
inactivity timers for non-POST methods in the (rather tiny) windows that are 
possible before it is cancelled, while for POST, it only allows to override 
*after* setting up the post tunnel with the origin, which is a little too late. 
There could be a potentially longer window when making the origin connection 
and the patch doesn't let the inactivity timer override in that window. 

So, if we agree to ignore the tiny windows for non-POST like methods where the 
timer could still be overridden, a more correct place for overriding the timer 
for POST seems to be the point where the timer is cancelled for non-POST 
methods (the one pasted by [~bcall] above) - i.e right before making a 
connection to the origin).

{{https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L6984}}

> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__main__':
> test_global_config()
> test_per_remap_config()
> {code}
> {{test_global_config()}} would pass, but {{test_per_remap_config()}} fails. 
> {{proxy.config.http.transaction_no_activity_timeout_in}} in per remap rule 
> does not works.



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

[jira] [Comment Edited] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3487 at 4/8/15 9:17 PM:


[~sudheerv] is correct, there are two timers at the same time (activity and 
inactivity).  Activity timers are scheduled using the scheduler and inactivity 
is a timestamp in the UnixNetVConnection and using the inactivity cop.  ATS can 
be compiled to use the scheduler for inactivity timeouts, but that is not the 
default.

Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}

If for some reason the inactivity timeout is not set a default one will be 
(default_inactivity_timeout).

Just tracked down this code, so the inactivity will be canceled, but then 
inactivity cop will set a default one:
{code}
  // Now that we have gotten the user agent request, we can cancel
  // the inactivity timeout associated with it.  Note, however, that
  // we must not cancel the inactivity timeout if the message
  // contains a body (as indicated by the non-zero request_content_length
  // field).  This indicates that a POST operation is taking place and
  // that the client is still sending data to the origin server.  The
  // origin server cannot reply until the entire request is received.  In
  // light of this dependency, TS must ensure that the client finishes
  // sending its request and for this reason, the inactivity timeout
  // cannot be cancelled.
  if (ua_session && !t_state.hdr_info.request_content_length) {
ua_session->get_netvc()->cancel_inactivity_timeout();
  }
{code}



was (Author: bcall):
[~sudheerv] is correct, there are two timers at the same time (activity and 
inactivity).  Activity timers are scheduled using the scheduler and inactivity 
is a timestamp in the UnixNetVConnection and using the inactivity cop.  ATS can 
be compiled to use the scheduler for inactivity timeouts, but that is not the 
default.

Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}

The inactivity timeout should always be set.  The inactivity timeout shouldn't 
be canceled on any request and it should be reset to a newer timestamp when 
there is activity.  If for some reason the inactivity timeout is not set a 
default one will be (default_inactivity_timeout).


Just tracked down this code, so the inactivity will be canceled, but then 
inactivity cop will set a default one.
{code}
  // Now that we have gotten the user agent request, we can cancel
  // the inactivity timeout associated with it.  Note, however, that
  // we must not cancel the inactivity timeout if the message
  // contains a body (as indicated by the non-zero request_content_length
  // field).  This indicates that a POST operation is taking place and
  // that the client is still sending data to the origin server.  The
  // origin server cannot reply until the entire request is received.  In
  // light of this dependency, TS must ensure that the client finishes
  // sending its request and for this reason, the inactivity timeout
  // cannot be cancelled.
  if (ua_session && !t_state.hdr_info.request_content_length) {
ua_session->get_netvc()->cancel_inactivity_timeout();
  }
{code}


> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> 

[jira] [Comment Edited] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3487 at 4/8/15 9:13 PM:


[~sudheerv] is correct, there are two timers at the same time (activity and 
inactivity).  Activity timers are scheduled using the scheduler and inactivity 
is a timestamp in the UnixNetVConnection and using the inactivity cop.  ATS can 
be compiled to use the scheduler for inactivity timeouts, but that is not the 
default.

Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}

The inactivity timeout should always be set.  The inactivity timeout shouldn't 
be canceled on any request and it should be reset to a newer timestamp when 
there is activity.  If for some reason the inactivity timeout is not set a 
default one will be (default_inactivity_timeout).


Just tracked down this code, so the inactivity will be canceled, but then 
inactivity cop will set a default one.
{code}
  // Now that we have gotten the user agent request, we can cancel
  // the inactivity timeout associated with it.  Note, however, that
  // we must not cancel the inactivity timeout if the message
  // contains a body (as indicated by the non-zero request_content_length
  // field).  This indicates that a POST operation is taking place and
  // that the client is still sending data to the origin server.  The
  // origin server cannot reply until the entire request is received.  In
  // light of this dependency, TS must ensure that the client finishes
  // sending its request and for this reason, the inactivity timeout
  // cannot be cancelled.
  if (ua_session && !t_state.hdr_info.request_content_length) {
ua_session->get_netvc()->cancel_inactivity_timeout();
  }
{code}



was (Author: bcall):
[~sudheerv] is correct, there are two timers at the same time (activity and 
inactivity).  Activity timers are scheduled using the scheduler and inactivity 
is a timestamp in the UnixNetVConnection and using the inactivity cop.  ATS can 
be compiled to use the scheduler for inactivity timeouts, but that is not the 
default.

Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}

The inactivity timeout should always be set.  The inactivity timeout shouldn't 
be canceled on any request and it should be reset to a newer timestamp when 
there is activity.  If for some reason the inactivity timeout is not set a 
default one will be (default_inactivity_timeout).


> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_rem

[jira] [Commented] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3487:


[~sudheerv] is correct, there are two timers at the same time (activity and 
inactivity).  Activity timers are scheduled using the scheduler and inactivity 
is a timestamp in the UnixNetVConnection and using the inactivity cop.  ATS can 
be compiled to use the scheduler for inactivity timeouts, but that is not the 
default.

Relevant methods:
{code}
UnixNetVConnection::set_active_timeout()
UnixNetVConnection::set_inactivity_timeout()
{code}

The inactivity timeout should always be set.  The inactivity timeout shouldn't 
be canceled on any request and it should be reset to a newer timestamp when 
there is activity.  If for some reason the inactivity timeout is not set a 
default one will be (default_inactivity_timeout).


> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__main__':
> test_global_config()
> test_per_remap_config()
> {code}
> {{test_global_config()}} would pass, but {{test_per_remap_config()}} fails. 
> {{proxy.config.http.transaction_no_activity_timeout_in}} in per remap rule 
> does not works.



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

[jira] [Comment Edited] (TS-3508) use accept4 on linux systems where available to reduce system calls

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3508 at 4/8/15 8:49 PM:
---

Cool :). So we can avoid setting the accepted socket to be nonblocking for 
example (avoding a sys call)?


was (Author: zwoop):
Cool :).

> use accept4 on linux systems where available to reduce system calls
> ---
>
> Key: TS-3508
> URL: https://issues.apache.org/jira/browse/TS-3508
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.0.0
>
>
> The accept4() syscall can set flags on the accepted socket.



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

[jira] [Updated] (TS-3508) use accept4 on linux systems where available to reduce system calls

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3508:
--
Assignee: John Plevyak

> use accept4 on linux systems where available to reduce system calls
> ---
>
> Key: TS-3508
> URL: https://issues.apache.org/jira/browse/TS-3508
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.0.0
>
>
> The accept4() syscall can set flags on the accepted socket.



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

[jira] [Commented] (TS-3508) use accept4 on linux systems where available to reduce system calls

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3508:
---

Cool :).

> use accept4 on linux systems where available to reduce system calls
> ---
>
> Key: TS-3508
> URL: https://issues.apache.org/jira/browse/TS-3508
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.0.0
>
>
> The accept4() syscall can set flags on the accepted socket.



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

[jira] [Updated] (TS-3508) use accept4 on linux systems where available to reduce system calls

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3508:
--
Fix Version/s: 6.0.0

> use accept4 on linux systems where available to reduce system calls
> ---
>
> Key: TS-3508
> URL: https://issues.apache.org/jira/browse/TS-3508
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network
>Reporter: John Plevyak
> Fix For: 6.0.0
>
>
> The accept4() syscall can set flags on the accepted socket.



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

[jira] [Created] (TS-3508) use accept4 on linux systems where available to reduce system calls

[John Plevyak (JIRA)]

John Plevyak created TS-3508:


 Summary: use accept4 on linux systems where available to reduce 
system calls
 Key: TS-3508
 URL: https://issues.apache.org/jira/browse/TS-3508
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network
Reporter: John Plevyak


The accept4() syscall can set flags on the accepted socket.



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

Build failed in Jenkins: out_of_tree-master #694

[jenkins]

See 

Changes:

[Bryan Call] TS-3507: Add stats for the milestones

[Bryan Call] TS-3507: updated CHANGES

--
[...truncated 1653 lines...]
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../mgmt/api -I../../lib/ts  -I../../../iocore/eventsystem 
-I../../../iocore/net -I../../../iocore/aio -I../../../iocore/hostdb 
-I../../../iocore/cache -I../../../iocore/cluster -I../../../iocore/utils 
-I../../../iocore/dns -I../../../lib/records -I../../../lib/ts -I../../../mgmt 
-I../../../mgmt/cluster -I../../../mgmt/utils -I../../../mgmt/api/include 
-I../../../lib -I../../lib  -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT NetworkUtilsRemote.lo -MD -MP -MF $depbase.Tpo 
-c -o NetworkUtilsRemote.lo ../../../mgmt/api/NetworkUtilsRemote.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo CfgContextImpl.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../mgmt/api -I../../lib/ts  -I../../../iocore/eventsystem 
-I../../../iocore/net -I../../../iocore/aio -I../../../iocore/hostdb 
-I../../../iocore/cache -I../../../iocore/cluster -I../../../iocore/utils 
-I../../../iocore/dns -I../../../lib/records -I../../../lib/ts -I../../../mgmt 
-I../../../mgmt/cluster -I../../../mgmt/utils -I../../../mgmt/api/include 
-I../../../lib -I../../lib  -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextImpl.lo -MD -MP -MF $depbase.Tpo -c 
-o CfgContextImpl.lo ../../../mgmt/api/CfgContextImpl.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo CfgContextManager.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../mgmt/api -I../../lib/ts  -I../../../iocore/eventsystem 
-I../../../iocore/net -I../../../iocore/aio -I../../../iocore/hostdb 
-I../../../iocore/cache -I../../../iocore/cluster -I../../../iocore/utils 
-I../../../iocore/dns -I../../../lib/records -I../../../lib/ts -I../../../mgmt 
-I../../../mgmt/cluster -I../../../mgmt/utils -I../../../mgmt/api/include 
-I../../../lib -I../../lib  -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextManager.lo -MD -MP -MF $depbase.Tpo 
-c -o CfgContextManager.lo ../../../mgmt/api/CfgContextManager.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo CfgContextUtils.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../mgmt/api -I../../lib/ts  -I../../../iocore/eventsystem 
-I../../../iocore/net -I../../../iocore/aio -I../../../iocore/hostdb 
-I../../../iocore/cache -I../../../iocore/cluster -I../../../iocore/utils 
-I../../../iocore/dns -I../../../lib/records -I../../../lib/ts -I../../../mgmt 
-I../../../mgmt/cluster -I../../../mgmt/utils -I../../../mgmt/api/include 
-I../../../lib -I../../lib  -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextUtils.lo -MD -MP -MF $depbase.Tpo -c 
-o CfgContextUtils.lo ../../../mgmt/api/CfgContextUtils.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  ccache c++ -DHAVE_CONFIG_H -I. -I../../../mgmt/api 
-I../../lib/ts -I../../../iocore/eventsystem -I../../../iocore/net 
-I../../../iocore/aio -I../../../iocore/hostdb -I../../../iocore/cache 
-I../../../iocore/cluster -I../../../iocore/utils -I../../../iocore/dns 
-I../../../lib/records -I../../../lib/ts -I../../../mgmt 
-I../../../mgmt/cluster -I../../../mgmt/utils -I../../../mgmt/api/include 
-I../../../lib -I../../lib -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-a

Build failed in Jenkins: in_tree-master #857

[jenkins]

See 

Changes:

[Bryan Call] TS-3507: Add stats for the milestones

[Bryan Call] TS-3507: updated CHANGES

--
[...truncated 2019 lines...]
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../lib/ts  -I../../iocore/eventsystem -I../../iocore/net 
-I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache 
-I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns 
-I../../lib/records -I../../lib/ts -I../../mgmt -I../../mgmt/cluster 
-I../../mgmt/utils -I../../mgmt/api/include -I../../lib -I../../lib  -Dlinux 
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT 
-D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN 
-I/usr/include/libxml2 -Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT NetworkUtilsRemote.lo -MD -MP -MF $depbase.Tpo 
-c -o NetworkUtilsRemote.lo NetworkUtilsRemote.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo CfgContextImpl.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../lib/ts  -I../../iocore/eventsystem -I../../iocore/net 
-I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache 
-I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns 
-I../../lib/records -I../../lib/ts -I../../mgmt -I../../mgmt/cluster 
-I../../mgmt/utils -I../../mgmt/api/include -I../../lib -I../../lib  -Dlinux 
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT 
-D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN 
-I/usr/include/libxml2 -Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextImpl.lo -MD -MP -MF $depbase.Tpo -c 
-o CfgContextImpl.lo CfgContextImpl.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo CfgContextManager.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../lib/ts  -I../../iocore/eventsystem -I../../iocore/net 
-I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache 
-I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns 
-I../../lib/records -I../../lib/ts -I../../mgmt -I../../mgmt/cluster 
-I../../mgmt/utils -I../../mgmt/api/include -I../../lib -I../../lib  -Dlinux 
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT 
-D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN 
-I/usr/include/libxml2 -Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextManager.lo -MD -MP -MF $depbase.Tpo 
-c -o CfgContextManager.lo CfgContextManager.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo CfgContextUtils.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../lib/ts  -I../../iocore/eventsystem -I../../iocore/net 
-I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache 
-I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns 
-I../../lib/records -I../../lib/ts -I../../mgmt -I../../mgmt/cluster 
-I../../mgmt/utils -I../../mgmt/api/include -I../../lib -I../../lib  -Dlinux 
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT 
-D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN 
-I/usr/include/libxml2 -Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextUtils.lo -MD -MP -MF $depbase.Tpo -c 
-o CfgContextUtils.lo CfgContextUtils.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  ccache c++ -DHAVE_CONFIG_H -I. -I../../lib/ts 
-I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio 
-I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster 
-I../../iocore/utils -I../../iocore/dns -I../../lib/records -I../../lib/ts 
-I../../mgmt -I../../mgmt/cluster -I../../mgmt/utils -I../../mgmt/api/include 
-I../../lib -I../../lib -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wunused-parameter -std=c++11 -g -pipe -Wall -O3 
-feliminate-unused-debug-symbols -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT CfgContextImpl.lo -MD -MP -MF 
.deps/CfgContextImpl.Tpo -c CfgContextImpl.cc  -fPIC -DPIC -o 
.libs/CfgContextImpl.o
libtool: compile:  ccache c++ -DHAVE_CONFIG_H -I. -I../../lib/ts 
-I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio 
-I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster 
-I../../iocore/utils -I../../iocore/dns 

[jira] [Resolved] (TS-3507) Add stats for the milestones

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-3507.

Resolution: Fixed

> Add stats for the milestones
> 
>
> Key: TS-3507
> URL: https://issues.apache.org/jira/browse/TS-3507
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Add milestones to the stats:
> Example:
> {code}
> [bcall@mac-bryan-wire ~]$ tsl -m milestone
> proxy.process.http.milestone.ua_begin 0
> proxy.process.http.milestone.ua_first_read 0
> proxy.process.http.milestone.ua_read_header_done 0
> proxy.process.http.milestone.ua_begin_write 882
> proxy.process.http.milestone.ua_close 1238
> proxy.process.http.milestone.server_first_connect 120
> proxy.process.http.milestone.server_connect 120
> proxy.process.http.milestone.server_connect_end 118
> proxy.process.http.milestone.server_begin_write 120
> proxy.process.http.milestone.server_first_read 882
> proxy.process.http.milestone.server_read_header_done 882
> proxy.process.http.milestone.server_close 1238
> proxy.process.http.milestone.cache_open_read_begin 0
> proxy.process.http.milestone.cache_open_read_end 0
> proxy.process.http.milestone.cache_open_write_begin 0
> proxy.process.http.milestone.cache_open_write_end 0
> proxy.process.http.milestone.dns_lookup_begin 0
> proxy.process.http.milestone.dns_lookup_end 120
> proxy.process.http.milestone.sm_start 0
> proxy.process.http.milestone.sm_finish 1238
> {code}



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

[jira] [Updated] (TS-3507) Add stats for the milestones

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3507:
---
Summary: Add stats for the milestones  (was: Add milestones to the stats)

> Add stats for the milestones
> 
>
> Key: TS-3507
> URL: https://issues.apache.org/jira/browse/TS-3507
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Add milestones to the stats:
> Example:
> {code}
> [bcall@mac-bryan-wire ~]$ tsl -m milestone
> proxy.process.http.milestone.ua_begin 0
> proxy.process.http.milestone.ua_first_read 0
> proxy.process.http.milestone.ua_read_header_done 0
> proxy.process.http.milestone.ua_begin_write 882
> proxy.process.http.milestone.ua_close 1238
> proxy.process.http.milestone.server_first_connect 120
> proxy.process.http.milestone.server_connect 120
> proxy.process.http.milestone.server_connect_end 118
> proxy.process.http.milestone.server_begin_write 120
> proxy.process.http.milestone.server_first_read 882
> proxy.process.http.milestone.server_read_header_done 882
> proxy.process.http.milestone.server_close 1238
> proxy.process.http.milestone.cache_open_read_begin 0
> proxy.process.http.milestone.cache_open_read_end 0
> proxy.process.http.milestone.cache_open_write_begin 0
> proxy.process.http.milestone.cache_open_write_end 0
> proxy.process.http.milestone.dns_lookup_begin 0
> proxy.process.http.milestone.dns_lookup_end 120
> proxy.process.http.milestone.sm_start 0
> proxy.process.http.milestone.sm_finish 1238
> {code}



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

[jira] [Commented] (TS-3507) Add milestones to the stats

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-3507:
-

Commit 77cb386d331c5a5a146de80fb0d6c536974b936b in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=77cb386 ]

TS-3507: Add stats for the milestones


> Add milestones to the stats
> ---
>
> Key: TS-3507
> URL: https://issues.apache.org/jira/browse/TS-3507
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Add milestones to the stats:
> Example:
> {code}
> [bcall@mac-bryan-wire ~]$ tsl -m milestone
> proxy.process.http.milestone.ua_begin 0
> proxy.process.http.milestone.ua_first_read 0
> proxy.process.http.milestone.ua_read_header_done 0
> proxy.process.http.milestone.ua_begin_write 882
> proxy.process.http.milestone.ua_close 1238
> proxy.process.http.milestone.server_first_connect 120
> proxy.process.http.milestone.server_connect 120
> proxy.process.http.milestone.server_connect_end 118
> proxy.process.http.milestone.server_begin_write 120
> proxy.process.http.milestone.server_first_read 882
> proxy.process.http.milestone.server_read_header_done 882
> proxy.process.http.milestone.server_close 1238
> proxy.process.http.milestone.cache_open_read_begin 0
> proxy.process.http.milestone.cache_open_read_end 0
> proxy.process.http.milestone.cache_open_write_begin 0
> proxy.process.http.milestone.cache_open_write_end 0
> proxy.process.http.milestone.dns_lookup_begin 0
> proxy.process.http.milestone.dns_lookup_end 120
> proxy.process.http.milestone.sm_start 0
> proxy.process.http.milestone.sm_finish 1238
> {code}



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

[jira] [Commented] (TS-3507) Add milestones to the stats

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on TS-3507:
-

Commit ca83b34cfed377faf53a44ec27b0065878b2492d in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ca83b34 ]

TS-3507: updated CHANGES


> Add milestones to the stats
> ---
>
> Key: TS-3507
> URL: https://issues.apache.org/jira/browse/TS-3507
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Add milestones to the stats:
> Example:
> {code}
> [bcall@mac-bryan-wire ~]$ tsl -m milestone
> proxy.process.http.milestone.ua_begin 0
> proxy.process.http.milestone.ua_first_read 0
> proxy.process.http.milestone.ua_read_header_done 0
> proxy.process.http.milestone.ua_begin_write 882
> proxy.process.http.milestone.ua_close 1238
> proxy.process.http.milestone.server_first_connect 120
> proxy.process.http.milestone.server_connect 120
> proxy.process.http.milestone.server_connect_end 118
> proxy.process.http.milestone.server_begin_write 120
> proxy.process.http.milestone.server_first_read 882
> proxy.process.http.milestone.server_read_header_done 882
> proxy.process.http.milestone.server_close 1238
> proxy.process.http.milestone.cache_open_read_begin 0
> proxy.process.http.milestone.cache_open_read_end 0
> proxy.process.http.milestone.cache_open_write_begin 0
> proxy.process.http.milestone.cache_open_write_end 0
> proxy.process.http.milestone.dns_lookup_begin 0
> proxy.process.http.milestone.dns_lookup_end 120
> proxy.process.http.milestone.sm_start 0
> proxy.process.http.milestone.sm_finish 1238
> {code}



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

[jira] [Assigned] (TS-3507) Add milestones to the stats

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-3507:
--

Assignee: Bryan Call

> Add milestones to the stats
> ---
>
> Key: TS-3507
> URL: https://issues.apache.org/jira/browse/TS-3507
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Add milestones to the stats:
> Example:
> {code}
> [bcall@mac-bryan-wire ~]$ tsl -m milestone
> proxy.process.http.milestone.ua_begin 0
> proxy.process.http.milestone.ua_first_read 0
> proxy.process.http.milestone.ua_read_header_done 0
> proxy.process.http.milestone.ua_begin_write 882
> proxy.process.http.milestone.ua_close 1238
> proxy.process.http.milestone.server_first_connect 120
> proxy.process.http.milestone.server_connect 120
> proxy.process.http.milestone.server_connect_end 118
> proxy.process.http.milestone.server_begin_write 120
> proxy.process.http.milestone.server_first_read 882
> proxy.process.http.milestone.server_read_header_done 882
> proxy.process.http.milestone.server_close 1238
> proxy.process.http.milestone.cache_open_read_begin 0
> proxy.process.http.milestone.cache_open_read_end 0
> proxy.process.http.milestone.cache_open_write_begin 0
> proxy.process.http.milestone.cache_open_write_end 0
> proxy.process.http.milestone.dns_lookup_begin 0
> proxy.process.http.milestone.dns_lookup_end 120
> proxy.process.http.milestone.sm_start 0
> proxy.process.http.milestone.sm_finish 1238
> {code}



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

[jira] [Updated] (TS-3507) Add milestones to the stats

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3507:
---
Fix Version/s: 6.0.0

> Add milestones to the stats
> ---
>
> Key: TS-3507
> URL: https://issues.apache.org/jira/browse/TS-3507
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> Add milestones to the stats:
> Example:
> {code}
> [bcall@mac-bryan-wire ~]$ tsl -m milestone
> proxy.process.http.milestone.ua_begin 0
> proxy.process.http.milestone.ua_first_read 0
> proxy.process.http.milestone.ua_read_header_done 0
> proxy.process.http.milestone.ua_begin_write 882
> proxy.process.http.milestone.ua_close 1238
> proxy.process.http.milestone.server_first_connect 120
> proxy.process.http.milestone.server_connect 120
> proxy.process.http.milestone.server_connect_end 118
> proxy.process.http.milestone.server_begin_write 120
> proxy.process.http.milestone.server_first_read 882
> proxy.process.http.milestone.server_read_header_done 882
> proxy.process.http.milestone.server_close 1238
> proxy.process.http.milestone.cache_open_read_begin 0
> proxy.process.http.milestone.cache_open_read_end 0
> proxy.process.http.milestone.cache_open_write_begin 0
> proxy.process.http.milestone.cache_open_write_end 0
> proxy.process.http.milestone.dns_lookup_begin 0
> proxy.process.http.milestone.dns_lookup_end 120
> proxy.process.http.milestone.sm_start 0
> proxy.process.http.milestone.sm_finish 1238
> {code}



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

[jira] [Created] (TS-3507) Add milestones to the stats

[Bryan Call (JIRA)]

Bryan Call created TS-3507:
--

 Summary: Add milestones to the stats
 Key: TS-3507
 URL: https://issues.apache.org/jira/browse/TS-3507
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Bryan Call


Add milestones to the stats:

Example:
{code}
[bcall@mac-bryan-wire ~]$ tsl -m milestone
proxy.process.http.milestone.ua_begin 0
proxy.process.http.milestone.ua_first_read 0
proxy.process.http.milestone.ua_read_header_done 0
proxy.process.http.milestone.ua_begin_write 882
proxy.process.http.milestone.ua_close 1238
proxy.process.http.milestone.server_first_connect 120
proxy.process.http.milestone.server_connect 120
proxy.process.http.milestone.server_connect_end 118
proxy.process.http.milestone.server_begin_write 120
proxy.process.http.milestone.server_first_read 882
proxy.process.http.milestone.server_read_header_done 882
proxy.process.http.milestone.server_close 1238
proxy.process.http.milestone.cache_open_read_begin 0
proxy.process.http.milestone.cache_open_read_end 0
proxy.process.http.milestone.cache_open_write_begin 0
proxy.process.http.milestone.cache_open_write_end 0
proxy.process.http.milestone.dns_lookup_begin 0
proxy.process.http.milestone.dns_lookup_end 120
proxy.process.http.milestone.sm_start 0
proxy.process.http.milestone.sm_finish 1238
{code}



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

[jira] [Updated] (TS-3506) ATS crashes with empty files in body-factory

[Theo Hoogerheide (JIRA)]

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

Theo Hoogerheide updated TS-3506:
-
Affects Version/s: 5.2.0
   5.2.1

> ATS crashes with empty files in body-factory
> 
>
> Key: TS-3506
> URL: https://issues.apache.org/jira/browse/TS-3506
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 5.2.0, 5.2.1
>Reporter: Theo Hoogerheide
>
> When making the files empty in the body-factory, ATS crashes when sending for 
> instance a 404:
> {code}
> traffic_server: Segmentation fault (Address not mapped to object [0x44])
> traffic_server - STACK TRACE:
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
> /usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
> /usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
> /usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
> /usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
> /usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
> /usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
> /usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
> /usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
> /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
> /usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
> /usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
> Segmentation fault (core dumped)
> {code}
> gdb:
> {code}
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/traffic_server -M --httpport 
> 8080:fd=8,8080:fd=9:ipv6'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  ink_atomic_increment (count=, mem= out>) at ink_atomic.h:89
> warning: Source file is more recent than executable.
> 89// ink_atomic_increment(ptr, count)
> {code}



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

[jira] [Commented] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3487:
---

My understanding is that both active and inactive timers run in parallel - 
starting the active timer doesn't automatically cancel the inactivity timer and 
vice-versa. More specifically, the inactive timer on the client vc is cancelled 
right before the origin connection is opened for requests that do not contain a 
body (e.g. GET), while for the requests that contain body (e.g. POST), it is 
cancelled after the first byte from the origin is received. So, there are 
clearly windows in which the inactivity timers are running for all types of 
requests and can be overridden. 

Even if you want to *ignore* those windows, I am not sure the patch attached 
works correctly. For example, with the attached patch, how do you override the 
inactivity timer for POST when the origin connection takes longer to set up 
(based on {{proxy.config.http.connect_attempts_max_retries}} and 
{{proxy.config.http.connect_attempts_timeout}}).?

If it's acceptable to everyone, I am fine to ignore the tiny windows in which 
the inactivity timer can still be overridden for non-POST transactions, but, I 
think the patch should handle well all possible states for POST.

{{https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L7019}}

> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__main__':
> test_global_config()
> test_per_remap_config()
> {code}
> {{test_global_config()}} would pass, but {{test_per_remap_config()}} fails. 
> {{proxy.config.http.transaction_no_activity_timeout_in}} in per remap rule 
> does not works.



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

[jira] [Comment Edited] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Feifei Cai (JIRA)]

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

Feifei Cai edited comment on TS-3487 at 4/8/15 3:39 PM:


Well, I think it makes sense that ATS starts a timer inside 
{{HttpSM::state_read_client_request_header}}, because the transaction may stall 
here. In my test case, I make the client send url and headers with sleep calls, 
this would stall {{HttpSM::state_read_client_request_header}}.

{noformat}
# before remap
s.send(url1)
time.sleep(2) # < global config
s.send(header1)
time.sleep(3) # < global config
s.send(header2)
{noformat}

If we do not start a timer here (before remap), there would be no timeout 
control when ATS stalls on "reading client request headers".

My patch adds a timer setup in POST start point, because the configuration may 
be overridden, we have to reset it with newest configuration. As you figured 
out, remap is just one case, it may be overridden at any hook point.

As to GET method, there's no client read/write during "read client request 
headers" and "send back response to client", so we do not need to change 
anything. Even the configuration may be overridden at some hook point, we do 
not need to reset the timer, since there's no timer until ATS start to "send 
back response to client".


was (Author: ffcai):
Well, I think it makes sense that ATS starts a timer inside 
{{HttpSM::state_read_client_request_header}}, because the transaction may stall 
here. In my test case, I make the client send url and headers with sleep calls, 
this would stall {{HttpSM::state_read_client_request_header}}.

{noformat}
# before remap
s.send(url1)
time.sleep(2) # < global config
s.send(header1)
time.sleep(3) # < global config
s.send(header2)
{noformat}

If we do not start here (before remap), there would be no timeout when ATS 
stalls on reading client request headers.

> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__mai

[jira] [Commented] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Feifei Cai (JIRA)]

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

Feifei Cai commented on TS-3487:


Well, I think it makes sense that ATS starts a timer inside 
{{HttpSM::state_read_client_request_header}}, because the transaction may stall 
here. In my test case, I make the client send url and headers with sleep calls, 
this would stall {{HttpSM::state_read_client_request_header}}.

{noformat}
# before remap
s.send(url1)
time.sleep(2) # < global config
s.send(header1)
time.sleep(3) # < global config
s.send(header2)
{noformat}

If we do not start here (before remap), there would be no timeout when ATS 
stalls on reading client request headers.

> cannot override proxy.config.http.transaction_no_activity_timeout_in per 
> remap rule for POST methold
> 
>
> Key: TS-3487
> URL: https://issues.apache.org/jira/browse/TS-3487
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.2.1
>Reporter: Feifei Cai
>Assignee: Bryan Call
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: TS-3487.diff
>
>
> The configuration and test are as follows:
> remap.config:
> {noformat}
> map /test1 http://httpbin.org
> map /test2 http://httpbin.org @plugin=conf_remap.so 
> @pparam=proxy.config.http.transaction_no_activity_timeout_in=15
> {noformat}
> records.config:
> {noformat}  
> CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 5
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING 
> http_cs|http_ss|inactivity.*|socket
> {noformat}  
> {code:title=test.py}
> import time
> import logging
> import socket
> log = logging.getLogger(__name__)
> logging.basicConfig(level=logging.INFO)
> import SocketServer
> url1 = 'POST /test1/post HTTP/1.1\r\n'
> url2 = 'POST /test2/post HTTP/1.1\r\n'
> header1 = 'Host: 127.0.0.1\r\n'
> # last header need additional '\r\n'
> header2 = 'Content-Length: 10\r\n\r\n'
> body1 = '12345'
> body2 = '67890'
> def get_socket():
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(('127.0.0.1', 8080))
> return s
> def test_global_config():
> s = get_socket()
> log.info('start test global config...')
> try:
> # before remap
> s.send(url1)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(2) # < global config
> s.send(body1)
> time.sleep(4) # < global config
> s.send(body2)
> log.info('test global config: pass!')
> except IOError:
> log.info('test global config: fail!')
> response = s.recv(4096)
> print response
> def test_per_remap_config():
> s = get_socket()
> log.info('start test per remap config...')
> try:
> # before remap
> s.send(url2)
> time.sleep(2) # < global config
> s.send(header1)
> time.sleep(3) # < global config
> s.send(header2)
> # after remap
> time.sleep(11) # < per remap config
> s.send(body1)
> time.sleep(13) # < per remap config
> s.send(body2)
> log.info('test per remap config: pass!')
> except IOError:
> log.info('test per remap config: fail!')
> response = s.recv(4096)
> print response
> if __name__ == '__main__':
> test_global_config()
> test_per_remap_config()
> {code}
> {{test_global_config()}} would pass, but {{test_per_remap_config()}} fails. 
> {{proxy.config.http.transaction_no_activity_timeout_in}} in per remap rule 
> does not works.



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

[jira] [Commented] (TS-3487) cannot override proxy.config.http.transaction_no_activity_timeout_in per remap rule for POST methold

[Feifei Cai (JIRA)]

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

Feifei Cai commented on TS-3487:


{{transaction_no_activity_timeout_in}} specifies how long ATS keeps connections 
to clients open if a transaction stalls. In my understanding, each time before 
ATS starts to read from or write to client (e.g. read client request headers, 
read client request body, write response to client...), we setup a 
{{transaction_no_activity_timeout_in}} timer, assuming that the transaction is 
on no-activity status. Once ATS read data from or write data to client, the 
transaction switches to active status, we reset the 
{{transaction_no_activity_timeout_in}} timer. The timer only runs between last 
read/write and next read/write. Every read/write will reset the timer, since a 
read/write means that the transaction switches status from no-activity status 
to active status.

In the current implementation, we set up {{transaction_no_activity_timeout_in}} 
timer at 2 points:
# {{HttpSM::state_read_client_request_header}}
# {{HttpTransact::SM_ACTION_API_SEND_RESPONSE_HDR}}
This works fine for GET method, because ATS read from or write to client only 
at these 2 points. However, for POST method, the point 
{{HttpSM::do_setup_post_tunnel}} is missed. We need to set up the timer with 
the newest configuration, because {{transaction_no_activity_timeout_in}} may 
have been overridden in some hook points between 
{{HttpSM::state_read_client_request_header}} and 
{{HttpSM::do_setup_post_tunnel}}.

Please take a look at the debug output as follows, it's the test result of my 
local python test:

{noformat}
$ traffic_server -T '(http_cs|http_ss|inactivity|socket)'
traffic_server: using root directory '/tmp/tsqa/base_envs/tmp9hwEUd'
[Apr  8 14:57:01.119] Server {0x7fa8e276c800} NOTE: Traffic Server is running 
unprivileged, not switching to user 'nobody'
[Apr  8 14:57:01.128] Server {0x7fa8e276c800} DEBUG: (inactivity_cop) default 
inactivity timeout is set to: 86400
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (socket) net_activity 
updating inactivity 0, NetVC=0x7fa8d8016600
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (http_cs) [0] session 
born, netvc 0x7fa8d8016600
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (http_cs) [0] Starting 
transaction 1 using sm [0]
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (socket) 
UnixNetVConnection::remove_from_keep_alive_lru NetVC=0x7fa8d8016600
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (socket) Set inactive 
timeout=1200, for NetVC=0x7fa8d8016600
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (socket) Set active 
timeout=9000, NetVC=0x7fa8d8016600
[Apr  8 14:57:04.683] Server {0x7fa8e276c800} DEBUG: (socket) Set inactive 
timeout=50, for NetVC=0x7fa8d8016600
[Apr  8 14:57:05.131] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016600 now: 1428505025131303369 timeout at: 1428505029 timeout in: 5
[Apr  8 14:57:06.141] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016600 now: 1428505026141133710 timeout at: 1428505029 timeout in: 5
[Apr  8 14:57:06.702] Server {0x7fa8e276c800} DEBUG: (socket) net_activity 
updating inactivity 50, NetVC=0x7fa8d8016600
[Apr  8 14:57:07.138] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016600 now: 1428505027138484319 timeout at: 1428505031 timeout in: 5
[Apr  8 14:57:08.137] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016600 now: 1428505028137647712 timeout at: 1428505031 timeout in: 5
[Apr  8 14:57:09.140] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016600 now: 1428505029140409681 timeout at: 1428505031 timeout in: 5
[Apr  8 14:57:09.687] Server {0x7fa8e276c800} DEBUG: (socket) net_activity 
updating inactivity 50, NetVC=0x7fa8d8016600
[Apr  8 14:57:09.687] Server {0x7fa8e276c800} DEBUG: (socket) ::open: 
setsockopt() TCP_NODELAY on socket
[Apr  8 14:57:09.687] Server {0x7fa8e276c800} DEBUG: (http_ss) [0] session 
born, netvc 0x7fa8d8016340
[Apr  8 14:57:09.687] Server {0x7fa8e276c800} DEBUG: (socket) Set inactive 
timeout=18000, for NetVC=0x7fa8d8016340
[Apr  8 14:57:09.687] Server {0x7fa8e276c800} DEBUG: (socket) Set active 
timeout=0, NetVC=0x7fa8d8016340
[Apr  8 14:57:09.687] Server {0x7fa8e276c800} DEBUG: (socket) read_disable 
updating inactivity_at 0, NetVC=0x7fa8d8016600
[Apr  8 14:57:09.917] Server {0x7fa8e276c800} DEBUG: (socket) net_activity 
updating inactivity 18000, NetVC=0x7fa8d8016340
[Apr  8 14:57:10.139] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016340 now: 1428505030139478064 timeout at: 1428506829 timeout in: 
1800
[Apr  8 14:57:10.139] Server {0x7fa8e276c800} DEBUG: (inactivity_cop_verbose) 
vc: 0x7fa8d8016600 now: 1428505030139478064 timeout at: 1428505034 ti

[jira] [Updated] (TS-3506) ATS crashes with empty files in body-factory

[Theo Hoogerheide (JIRA)]

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

Theo Hoogerheide updated TS-3506:
-
Description: 
When making the files empty in the body-factory, ATS crashes when sending for 
instance a 404:

{code}
traffic_server: Segmentation fault (Address not mapped to object [0x44])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
/usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
/usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
/usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
/usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
/usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
/usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
/usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
/usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
/usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
/usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
/usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
/usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
/usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
/usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
Segmentation fault (core dumped)
{code}

gdb:
{code}
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/traffic_server -M --httpport 
8080:fd=8,8080:fd=9:ipv6'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  ink_atomic_increment (count=, mem=) 
at ink_atomic.h:89

warning: Source file is more recent than executable.
89  // ink_atomic_increment(ptr, count)
{code}

  was:
When making the files empty in the body-factory, ATS crashes when sending for 
instance a 404:

{code}
traffic_server: Segmentation fault (Address not mapped to object [0x44])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
/usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
/usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
/usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
/usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
/usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
/usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
/usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
/usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
/usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
/usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
/usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
/usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
/usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
/usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
Segmentation fault (core dumped)
{code}

GDB:
{code}
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/traffic_server -M --httpport 
8080:fd=8,8080:fd=9:ipv6'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  ink_atomic_increment (count=, mem=) 
at ink_atomic.h:89

warning: Source file is more recent than executable.
89  // ink_atomic_increment(ptr, count)
{code}


> ATS crashes with empty files in body-factory
> 
>
> Key: TS-3506
> URL: https://issues.apache.org/jira/browse/TS-3506
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Theo Hoogerheide
>
> When making the files emp

[jira] [Created] (TS-3506) ATS crashes with empty files in body-factory

[Theo Hoogerheide (JIRA)]

Theo Hoogerheide created TS-3506:


 Summary: ATS crashes with empty files in body-factory
 Key: TS-3506
 URL: https://issues.apache.org/jira/browse/TS-3506
 Project: Traffic Server
  Issue Type: Bug
Reporter: Theo Hoogerheide


When making the files empty in the body-factory, ATS crashes when sending for 
instance a 404:

{code}
traffic_server: Segmentation fault (Address not mapped to object [0x44])
traffic_server - STACK TRACE:
/usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x97)[0x7f4fe0280ee7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f4fdead4340]
/usr/lib/trafficserver/libtsutil.so.5(reclaimable_freelist_free+0x27)[0x7f4fdfd75107]
/usr/bin/traffic_server(_ZN12IOBufferData7deallocEv+0x74)[0x7f4fe0416ca4]
/usr/bin/traffic_server(_ZN12IOBufferData4freeEv+0x9)[0x7f4fe0416e29]
/usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x86)[0x7f4fe0417056]
/usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
/usr/bin/traffic_server(_ZN13IOBufferBlock5clearEv+0x42)[0x7f4fe0417012]
/usr/bin/traffic_server(_ZN13IOBufferBlock4freeEv+0x9)[0x7f4fe0417069]
/usr/bin/traffic_server(_ZN10HttpTunnel18deallocate_buffersEv+0x306)[0x7f4fe039c566]
/usr/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x42)[0x7f4fe039e0e2]
/usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x301)[0x7f4fe0364041]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xf8)[0x7f4fe0364a98]
/usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xb8)[0x7f4fe03a0248]
/usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x15ea)[0x7f4fe04b98ba]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x334)[0x7f4fe04ae594]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x100)[0x7f4fe04d8560]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x50b)[0x7f4fe04d8d5b]
/usr/bin/traffic_server(main+0xd47)[0x7f4fe026a237]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f4fddcfcec5]
/usr/bin/traffic_server(+0xc31f7)[0x7f4fe02711f7]
Segmentation fault (core dumped)
{code}

GDB:
{code}
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/traffic_server -M --httpport 
8080:fd=8,8080:fd=9:ipv6'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  ink_atomic_increment (count=, mem=) 
at ink_atomic.h:89

warning: Source file is more recent than executable.
89  // ink_atomic_increment(ptr, count)
{code}



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