[jira] [Updated] (TS-3918) Runtime option to disable freelists

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3918:
--
Summary: Runtime option to disable freelists  (was: runtime option to 
disable freelists)

> Runtime option to disable freelists
> ---
>
> Key: TS-3918
> URL: https://issues.apache.org/jira/browse/TS-3918
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> Disabling the free list is helpful for debugging and could also be useful for 
> memory-constrained deployments. Make this a run-time option (will require a 
> {{traffic_server}} restart).



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

[jira] [Updated] (TS-3924) Simplify debugging macros in cache_range_requests plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3924:
--
Summary: Simplify debugging macros in cache_range_requests plugin  (was: 
simplify debugging macros in cache_range_requests plugin)

> Simplify debugging macros in cache_range_requests plugin
> 
>
> Key: TS-3924
> URL: https://issues.apache.org/jira/browse/TS-3924
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 6.1.0
>
>
> Tidy up the debug logging in {{cache_range_requests}} and introduce 
> appropriate macros.



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

[jira] [Updated] (TS-3905) proxy.config.http.keep_alive_no_activity_timeout_out is not used

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3905:
--
Fix Version/s: (was: 6.1.0)

> proxy.config.http.keep_alive_no_activity_timeout_out is not used
> 
>
> Key: TS-3905
> URL: https://issues.apache.org/jira/browse/TS-3905
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> The keep_alive_no_activity_timeout_in is set correctly on the 
> HttpClientSession when the transaction releases it.  The client session is 
> then hanging out until the next transaction appears, and the 
> keep_alive_no_activity_timeout_in should apply instead of the 
> transaction_no_activity_timeout_in.
> For the server session side, the keep_alive_no_activity_timeout_out and 
> transaction_no_activity_timeout_out should apply.  The 
> keep_alive_no_activity_timeout_out does get set correctly when the server 
> session is attached to the client session to timeout via the 
> HttpClientSession::attach_server_session_method().
> But in ServerSessionPool::releaseSession, the following is called
> {code}
> ss->get_netvc()->set_inactivity_timeout(ss->get_netvc()->get_inactivity_timeout());
> {code}
> My reading is that this will reset the inactivity timeout of the server 
> session to whatever it was last set to.  Instead it should set the inactivity 
> timeout to keep_alive_no_activity_timeout_out.



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

[jira] [Updated] (TS-3363) core dump in HttpSM::handle_server_setup_error when handling inactivity timer expiry

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3363:
--
Fix Version/s: (was: 6.1.0)

> core dump in HttpSM::handle_server_setup_error when handling inactivity timer 
> expiry
> 
>
> Key: TS-3363
> URL: https://issues.apache.org/jira/browse/TS-3363
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Bryan Call
>
> The core dump is caused by missing null check for *c* here 
> {{https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L5250}}
>  although, it seems that *c* shouldn't be null at this point (if *tunnel* is 
> active).
> {code}
> (gdb) bt
> #0  0x005daca9 in HttpSM::handle_server_setup_error 
> (this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:5188
> #1  0x005cf16f in HttpSM::state_read_server_response_header 
> (this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:1750
> #2  0x005d19ae in HttpSM::main_handler (this=0x2b906c5d8f10, 
> event=105, data=0x2b8e183b8300) at HttpSM.cc:2522
> #3  0x004f6bb8 in Continuation::handleEvent (this=0x2b906c5d8f10, 
> event=105, data=0x2b8e183b8300) at ../iocore/eventsystem/I_Continuation.h:146
> #4  0x007379b3 in read_signal_and_update (event=105, 
> vc=0x2b8e183b81f0) at UnixNetVConnection.cc:141
> #5  0x0073a928 in UnixNetVConnection::mainEvent (this=0x2b8e183b81f0, 
> event=1, e=0x2771150) at UnixNetVConnection.cc:1071
> #6  0x004f6bb8 in Continuation::handleEvent (this=0x2b8e183b81f0, 
> event=1, data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
> #7  0x00731eba in InactivityCop::check_inactivity (this=0x2647ba0, 
> event=2, e=0x2771150) at UnixNet.cc:100
> #8  0x004f6bb8 in Continuation::handleEvent (this=0x2647ba0, event=2, 
> data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
> #9  0x0075858e in EThread::process_event (this=0x2b8c9eb56010, 
> e=0x2771150, calling_code=2) at UnixEThread.cc:145
> #10 0x007588a9 in EThread::execute (this=0x2b8c9eb56010) at 
> UnixEThread.cc:224
> #11 0x00757b0c in spawn_thread_internal (a=0x2642360) at Thread.cc:88
> #12 0x2b8c9c6d8851 in __free_tcb () from /lib64/libpthread.so.0
> #13 0x in ?? ()
> (gdb) print c
> $1 = (HttpTunnelConsumer *) 0x0
> (gdb) p post_transform_info.vc
> $2 = (VConnection *) 0x0
> (gdb) p post_transform_info
> $3 = {entry = 0x0, vc = 0x0}
> (gdb) p tunnel
> $4 = { = { = {_vptr.force_VFPT_to_top = 
> 0x7900d0}, handler = (int (Continuation::*)(Continuation *, int, void *)) 
> 0x61a23e
>  , mutex = {m_ptr = 
> 0x2b8db912c7e0}, link = { = {next = 0x0}, prev = 0x0}}, 
> num_producers = 1, num_consumers = 1, consumers = {{
>   link = { = {next = 0x0}, prev = 0x0}, 
> producer = 0x2b906c5d9d30, self_producer = 0x0, vc_type = HT_HTTP_CLIENT, vc 
> = 0x2b8ec5e96d50, 
>   buffer_reader = 0x2b8db3149e50, vc_handler = (int (HttpSM::*)(HttpSM *, 
> int, HttpTunnelConsumer *)) 0x5d3078 
> , 
>   write_vio = 0x2b8e1883baf8, skip_bytes = 0, bytes_written = 0, 
> handler_state = 0, alive = true, write_success = false, name = 0x78e839 "user 
> agent"}, {
>   link = { = {next = 0x0}, prev = 0x0}, 
> producer = 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 0x0, 
> buffer_reader = 0x0, vc_handler = NULL, 
>   write_vio = 0x0, skip_bytes = 0, bytes_written = 0, handler_state = 0, 
> alive = false, write_success = false, name = 0x0}, {link = 
> { = {next = 0x0}, prev = 0x0}, 
>   producer = 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 
> 0x0, buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0, skip_bytes = 0, 
> bytes_written = 0, handler_state = 0, 
>   alive = false, write_success = false, name = 0x0}, {link = 
> { = {next = 0x0}, prev = 0x0}, producer = 0x0, 
> self_producer = 0x0, vc_type = HT_HTTP_SERVER, 
>   vc = 0x0, buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0, 
> skip_bytes = 0, bytes_written = 0, handler_state = 0, alive = false, 
> write_success = false, name = 0x0}}, producers = {{
>   consumer_list = {head = 0x2b906c5d9b70}, self_consumer = 0x0, vc = 0x1, 
> vc_handler = NULL, read_vio = 0x0, read_buffer = 0x2b8db3149e10, buffer_start 
> = 0x0, vc_type = HT_STATIC, 
>   chunked_handler = {static DEFAULT_MAX_CHUNK_SIZE = 4096, action = 
> ChunkedHandler::ACTION_DOCHUNK, chunked_reader = 0x0, dechunked_buffer = 0x0, 
> dechunked_size = 0, dechunked_reader = 0x0, 
> chunked_buffer = 0x0, chunked_size = 0, truncation = 

[jira] [Updated] (TS-4049) CID 1341500: Null pointer dereferences: Lua plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4049:
--
Fix Version/s: (was: 6.1.0)

> CID 1341500:  Null pointer dereferences: Lua plugin
> ---
>
> Key: TS-4049
> URL: https://issues.apache.org/jira/browse/TS-4049
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua
>Reporter: Leif Hedstrom
>Assignee: Kit Chan
>  Labels: Coverity
>
> {code}
> ** CID 1341500:  Null pointer dereferences  (NULL_RETURNS)
> /plugins/experimental/ts_lua/ts_lua_http.c: 354 in 
> ts_lua_http_set_server_resp_no_store()
> 
> *** CID 1341500:  Null pointer dereferences  (NULL_RETURNS)
> /plugins/experimental/ts_lua/ts_lua_http.c: 354 in 
> ts_lua_http_set_server_resp_no_store()
> 348   ts_lua_http_ctx *http_ctx;
> 349 
> 350   http_ctx = ts_lua_get_http_ctx(L);
> 351 
> 352   status = luaL_checknumber(L, 1);
> 353 
>CID 1341500:  Null pointer dereferences  (NULL_RETURNS)
>Dereferencing a null pointer "http_ctx".
> 354   TSHttpTxnServerRespNoStoreSet(http_ctx->txnp, status);
> 355 
> 356   return 0;
> 357 }
> 358 
> 359 static int
> {code}



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

[jira] [Updated] (TS-4015) Add a transaction method to set the HTTP return status

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4015:
--
Fix Version/s: (was: 6.1.0)

> Add a transaction method to set the HTTP return status
> --
>
> Key: TS-4015
> URL: https://issues.apache.org/jira/browse/TS-4015
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: CPP API
>Reporter: Boaz Reicher
>Assignee: Sudheer Vinukonda
>  Labels: review
> Attachments: patch-4015.diff
>
>
> The Transaction class should have a method that allows setting the HTTP 
> return status without requiring a Response object.  Primarily needed for 
> setting error responses.



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

[jira] [Updated] (TS-4111) Typo: Fix a typo in traffic_via command reference

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4111:
--
Fix Version/s: (was: 6.1.0)
   Docs

> Typo: Fix a typo in traffic_via command reference
> -
>
> Key: TS-4111
> URL: https://issues.apache.org/jira/browse/TS-4111
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> taht are enclosed by square brackets.
> -> that are enclosed by square brackets.
> I created a pull request to fix this typo: 
> https://github.com/apache/trafficserver/pull/404



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

[jira] [Updated] (TS-3858) Remove xfree cruft

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3858:
--
Component/s: Core

> Remove xfree cruft
> --
>
> Key: TS-3858
> URL: https://issues.apache.org/jira/browse/TS-3858
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>Priority: Trivial
> Fix For: 6.1.0
>
>




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

[jira] [Updated] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3792:
--
Component/s: DNS

> Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file 
> causes segmentation faults on first DNS query
> -
>
> Key: TS-3792
> URL: https://issues.apache.org/jira/browse/TS-3792
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> {code}
> [connect] ERROR (main_socket_fd 9): Connection refused
> [Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to 
> /var/log/trafficserver/crash-2015-07-22-170434.log
> traffic_server: Floating point exception (Integer divide by zero 
> [0x6d8e5a])traffic_server - STACK TRACE: 
> traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
> /lib64/libpthread.so.0[0x340d40f710]
> traffic_server[0x6d8e5a]
> traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
> traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
> traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
> traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
> traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
> traffic_server(main+0x1246)[0x53da75]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
> traffic_server[0x4f47a9]
> Floating point exception (core dumped)
> {code}



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

[jira] [Updated] (TS-3797) Crashes due to cross-thread race conditions

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3797:
--
Component/s: Core

> Crashes due to cross-thread race conditions
> ---
>
> Key: TS-3797
> URL: https://issues.apache.org/jira/browse/TS-3797
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.1.0
>
>
>  We had seen crashes with the following stack trace occasionally, but 
> recently we have found an environment where these crashes happen so 
> frequently that running ATS with global session pools is not feasible.
> {code}
> #0  0x004fac6e in Ptr::operator IOBufferBlock* (
> this=0x10) at ../lib/ts/Ptr.h:300
> #1  0x005109a2 in IOBufferReader::read_avail (this=0x0)
> at ../iocore/eventsystem/P_IOBuffer.h:606
> #2  0x00777b54 in write_to_net_io (nh=0x2acc365358a0, 
> vc=0x2acd38024960, thread=0x2acc36532010) at UnixNetVConnection.cc:540
> #3  0x0077747a in write_to_net (nh=0x2acc365358a0, vc=0x2acd38024960, 
> thread=0x2acc36532010) at UnixNetVConnection.cc:407
> #4  0x00770378 in NetHandler::mainNetEvent (this=0x2acc365358a0, 
> event=5, e=0x2244730) at UnixNet.cc:562
> #5  0x00510560 in Continuation::handleEvent (this=0x2acc365358a0, 
> event=5, data=0x2244730) at ../iocore/eventsystem/I_Continuation.h:145
> #6  0x00796ffe in EThread::process_event (this=0x2acc36532010, 
> e=0x2244730, calling_code=5) at UnixEThread.cc:128
> #7  0x00797508 in EThread::execute (this=0x2acc36532010)
> at UnixEThread.cc:252
> #8  0x007965a9 in spawn_thread_internal (a=0x2115540) at Thread.cc:85
> #9  0x2acc2edd49d1 in start_thread () from /lib64/libpthread.so.0
> #10 0x0032750e88fd in clone () from /lib64/libc.so.6
> {code}
> See 
> https://cwiki.apache.org/confluence/display/TS/Threading+Issues+And+NetVC+Migration
>  for analysis of the crash and a suggested solution.



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

[jira] [Updated] (TS-4050) Crash when buckets=0 is configured in cache_promote plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4050:
--
Summary: Crash when buckets=0 is configured in cache_promote plugin  (was: 
Trafficserver is crashing when buckets=0 is configured in cache_promote plugin)

> Crash when buckets=0 is configured in cache_promote plugin
> --
>
> Key: TS-4050
> URL: https://issues.apache.org/jira/browse/TS-4050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Meera Mosale Nataraja
>Assignee: Meera Mosale Nataraja
> Fix For: 6.1.0
>
>
> I configured buckets=0 for cache_promote plugin and traffic server is 
> crashing with following backtrace.
> (gdb) bt
> #0  0x7f71240b97d3 in 
> std::_List_node_base::transfer(std::_List_node_base*, std::_List_node_base*) 
> () from /usr/lib64/libstdc++.so.6
> #1  0x7f711c8eb4f8 in _M_transfer (this=0x7f71299c7850, txnp= optimized out>) at 
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_list.h:1400
> #2  splice (this=0x7f71299c7850, txnp=) at 
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_list.h:1187
> #3  LRUPolicy::doPromote (this=0x7f71299c7850, txnp=) at 
> cache_promote.cc:253
> #4  0x7f711c8ea758 in cont_handle_policy (contp=0x7f71299a2f40, 
> event=, edata=0x7f712f8a2970) at cache_promote.cc:397
> #5  0x7f7126de559a in HttpSM::state_api_callout (this=0x7f712f8a2970, 
> event=, data=) at HttpSM.cc:1381
> #6  0x7f7126de6ef0 in do_api_callout (this=0x7f712f8a2970, event= optimized out>, data=0xb050) at HttpSM.cc:442
> #7  setup_cache_lookup_complete_api (this=0x7f712f8a2970, event= optimized out>, data=0xb050) at HttpSM.cc:2450
> #8  HttpSM::state_cache_open_read (this=0x7f712f8a2970, event= optimized out>, data=0xb050) at HttpSM.cc:2511
> #9  0x7f7126de6be8 in HttpSM::main_handler (this=0x7f712f8a2970, 
> event=1103, data=0xb050) at HttpSM.cc:2553
> #10 0x7f7126dc94a2 in handleEvent (this=0x7f712f8a4398, event=1103, 
> data=0xb050) at ../../iocore/eventsystem/I_Continuation.h:145
> #11 HttpCacheSM::state_cache_open_read (this=0x7f712f8a4398, event=1103, 
> data=0xb050) at HttpCacheSM.cc:131
> #12 0x7f7126f44e56 in Cache::open_read (this=, 
> cont=0x7f712f8a4398, key=, request=0x7f712f8a3078, 
> params=0x7f712f8a2a50, type=, 
> #13 0x7f7126f20fb8 in open_read (this=, 
> cont=0x7f712f8a4398, url=0x7f712f8a3090, cluster_cache_local= out>, request=0x7f712f8a3078, params=0x7f712f8a2a50, pin_in_cache=0, 
> type=CACHE_FRAG_TYPE_HTTP)
>at P_CacheInternal.h:1074
> #14 CacheProcessor::open_read (this=, 
> cont=0x7f712f8a4398, url=0x7f712f8a3090, cluster_cache_local= out>, request=0x7f712f8a3078, params=0x7f712f8a2a50, pin_in_cache=0, 
> type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3598
> #15 0x7f7126dc8eed in do_cache_open_read (this=, 
> url=, hdr=, params= out>, pin_in_cache=) at HttpCacheSM.cc:211
> #16 HttpCacheSM::open_read (this=, url= out>, hdr=, params=, 
> pin_in_cache=) at HttpCacheSM.cc:243
> #17 0x7f7126dd723e in HttpSM::do_cache_lookup_and_read 
> (this=0x7f712f8a2970) at HttpSM.cc:4388
> #18 0x7f7126deee42 in HttpSM::set_next_state (this=0x7f712f8a2970) at 
> HttpSM.cc:6997
> #19 0x7f7126df205f in HttpSM::handle_api_return (this=0x7f712f8a2970) at 
> HttpSM.cc:1517
> #20 0x7f7126de5738 in HttpSM::state_api_callout (this=0x7f712f8a2970, 
> event=0, data=0x0) at HttpSM.cc:1455
> #21 0x7f7126deec85 in HttpSM::set_next_state (this=0x7f712f8a2970) at 
> HttpSM.cc:6887
> #22 0x7f7126deec75 in HttpSM::set_next_state (this=0x7f712f8a2970) at 
> HttpSM.cc:6901
> #23 0x7f7126df205f in HttpSM::handle_api_return (this=0x7f712f8a2970) at 
> HttpSM.cc:1517
> #24 0x7f7126de5738 in HttpSM::state_api_callout (this=0x7f712f8a2970, 
> event=0, data=0x0) at HttpSM.cc:1455
> #25 0x7f7126deec85 in HttpSM::set_next_state (this=0x7f712f8a2970) at 
> HttpSM.cc:6887
> #26 0x7f7126df205f in HttpSM::handle_api_return (this=0x7f712f8a2970) at 
> HttpSM.cc:1517
> #27 0x7f7126de5738 in HttpSM::state_api_callout (this=0x7f712f8a2970, 
> event=0, data=0x0) at HttpSM.cc:1455
> #28 0x7f7126deec85 in HttpSM::set_next_state (this=0x7f712f8a2970) at 
> HttpSM.cc:6887
> #29 0x7f7126de3515 in HttpSM::state_read_client_request_header 
> (this=0x7f712f8a2970, event=100, data=) at HttpSM.cc:777
> #30 0x7f7126de6be8 in HttpSM::main_handler (this=0x7f712f8a2970, 
> event=100, data=0x7f712f705e58) at HttpSM.cc:2553
> #31 0x7f7126df204c in handleEvent (this=0x7f712f8a2970) at 
> ../../iocore/eventsystem/I_Continuation.h:145
> #32 setup_client_read_request_header (this=0x7f712f8a2970) at HttpSM.cc:603
> #33 HttpSM::handle_api_return 

[jira] [Updated] (TS-4051) header_rewrite: Add a debug statement for the set-conn-dscp action

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4051:
--
Issue Type: Improvement  (was: Bug)

> header_rewrite: Add a debug statement for the set-conn-dscp action
> --
>
> Key: TS-4051
> URL: https://issues.apache.org/jira/browse/TS-4051
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {code}
> +TSDebug(PLUGIN_NAME, "   Setting DSCP to %d", _ds_value.get_int_value());
> {code}



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

[jira] [Updated] (TS-4047) Multiple -rpath options are not handled correctly

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4047:
--
Summary: Multiple -rpath options are not handled correctly  (was: multiple 
-rpath options are not handled correctly)

> Multiple -rpath options are not handled correctly
> -
>
> Key: TS-4047
> URL: https://issues.apache.org/jira/browse/TS-4047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> https://github.com/apache/trafficserver/pull/324
> {quote}
> Using TS_ADDTO to add the custom locations of libraries results in incorrect 
> "-rpath" directive to the linker. This is because TS_ADDTO creates a unique 
> list of tokens that it adds to its target. E.g.,
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib
> the above should result in
> LIBTOOL_LINK_FLAGS: -rpath /usr/local/openssl/lib /usr/local/zlib/lib
> The absence of "-rpath" in front of the second path causes an error in the 
> linker!
> This is fixed by introducing a new macro TS_ADD_RPATH_TO that takes a path 
> and adds it with the "-rpath " prefix.
> Also added influential environmental variable RPATH that can be used to give 
> a base value for the rpath. So, the following
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib 
> RPATH=/foo
> will result in
> LIBTOOL_LINK_FLAGS: -rpath /foo -rpath /usr/local/zlib/lib -rpath 
> /usr/local/openssl/lib
> {quote}



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

[jira] [Updated] (TS-4060) traffic_layout JSON option does't always work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4060:
--
Issue Type: Improvement  (was: Bug)

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Updated] (TS-4052) auto_ptr is deprecated and should not be used in our code

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4052:
--
Issue Type: Improvement  (was: Bug)

> auto_ptr is deprecated and should not be used in our code
> -
>
> Key: TS-4052
> URL: https://issues.apache.org/jira/browse/TS-4052
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> I get the following build warnings:
> {code}
> In file included from ats-multiplexer.cc:29:0:
> dispatch.h:54:8: warning: 'template class std::auto_ptr' is deprecated 
> [-Wdeprecated-declarations]
>std::auto_ptr io;
> ^
> In file included from /opt/gcc5/include/c++/5.2.0/memory:81:0,
>  from dispatch.h:27,
>  from ats-multiplexer.cc:29:
> /opt/gcc5/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here
>template class auto_ptr;
> ^
>   CXX  chunk-decoder.lo
>   CXX  dispatch.lo
> In file included from dispatch.cc:26:0:
> dispatch.h:54:8: warning: 'template class std::auto_ptr' is deprecated 
> [-Wdeprecated-declarations]
>std::auto_ptr io;
> ^
> In file included from /opt/gcc5/include/c++/5.2.0/memory:81:0,
>  from dispatch.h:27,
>  from dispatch.cc:26:
> /opt/gcc5/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here
>template class auto_ptr;
> ^
>   CXX  fetcher.lo
>   CXX  original-request.lo
> In file included from original-request.cc:25:0:
> dispatch.h:54:8: warning: 'template class std::auto_ptr' is deprecated 
> [-Wdeprecated-declarations]
>std::auto_ptr io;
> ^
> In file included from /opt/gcc5/include/c++/5.2.0/memory:81:0,
>  from dispatch.h:27,
>  from original-request.cc:25:
> /opt/gcc5/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here
>template class auto_ptr;
> ^
>   CXX  post.lo
> In file included from post.h:28:0,
>  from post.cc:26:
> dispatch.h:54:8: warning: 'template class std::auto_ptr' is deprecated 
> [-Wdeprecated-declarations]
>std::auto_ptr io;
> ^
> In file included from /opt/gcc5/include/c++/5.2.0/memory:81:0,
>  from dispatch.h:27,
>  from post.h:28,
>  from post.cc:26:
> /opt/gcc5/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here
>template class auto_ptr;
> {code}
> I'm not sure what's the best option here, but we've used ats_scoped_obj in 
> plugins even though it's not a public API.



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

[jira] [Updated] (TS-4036) Make Lua build flags consistent

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4036:
--
Summary: Make Lua build flags consistent  (was: make Lua build flags 
consistent)

> Make Lua build flags consistent
> ---
>
> Key: TS-4036
> URL: https://issues.apache.org/jira/browse/TS-4036
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> The Lua build flags suffer from inconsistent naming and some missing build 
> variables.



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

[jira] [Updated] (TS-3881) New TS API TSHttpTxnInfoIntGet.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3881:
--
Summary: New TS API TSHttpTxnInfoIntGet.  (was: new TS API 
TSHttpTxnInfoIntGet.)

> New TS API TSHttpTxnInfoIntGet.
> ---
>
> Key: TS-3881
> URL: https://issues.apache.org/jira/browse/TS-3881
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: TS API
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> I started off trying to write a TSHttpTxnCacheStateGet API to return cache 
> lookup specific details, but, based on feed back on the IRC and dev@, 
> changing the API to a more generic interface TSHttpTxnInfoIntGet to return 
> any arbitrary info. The idea is to be able to use this API in the long term 
> to support any arbitrary information related to a Txn (which can be used as 
> the underlying piece for a framework to return txn info using custom log 
> tags).
> Below's the proposal with the info I'd like the new API return along with the 
> API signature.
> Please provide comments/suggestions.
> {code}
> +typedef enum {
> +  TS_TXN_INFO_CACHE_HIT_RAM,
> +  TS_TXN_INFO_COMPRESSED_IN_RAM,
> +  TS_TXN_INFO_CACHE_HIT_RWW, // READ_WHILE_WRITE
> +  TS_TXN_INFO_CACHE_OPEN_READ_TRIES,
> +  TS_TXN_INFO_CACHE_OPEN_WRITE_TRIES,
> +  TS_TXN_INFO_CACHE_VOLUME,
> +  TS_TXN_INFO_LAST_ENTRY
> +} TSHttpTxnInfoKey;
> +
> +/* Get Arbitrary Txn info such as cache lookup details etc as defined in 
> TSHttpTxnInfoKey */
> +/**
> +   Return the particular txn info requested.
> +
> +   @param txnp the transaction pointer
> +   @param key the requested txn info.
> +   @param TSMgmtInt a pointer to a integer where the return value is stored
> +
> +   @return @c TS_SUCCESS if the requested info is supported, TS_ERROR 
> otherwise
> +
> +*/
> +tsapi TSReturnCode TSHttpTxnInfoIntGet(TSHttpTxn txnp, TSHttpTxnInfoKey key, 
> TSMgmtInt *value);
> +
> {code}
> +



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

[jira] [Updated] (TS-3880) Remove MEMPROTECT cruft

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3880:
--
Component/s: Core

> Remove MEMPROTECT cruft
> ---
>
> Key: TS-3880
> URL: https://issues.apache.org/jira/browse/TS-3880
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 6.1.0
>
>
> This code is only enabled by manually uncommenting a #define. It's likely 
> never used or tested and does not look to do anything useful anyway. It never 
> calls mprotect() in a positive way.



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

[jira] [Updated] (TS-3998) Disable h2c upgrades (for now)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3998:
--
Issue Type: Improvement  (was: Bug)

> Disable h2c upgrades (for now)
> --
>
> Key: TS-3998
> URL: https://issues.apache.org/jira/browse/TS-3998
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
> Fix For: 6.1.0
>
>
> I see
> {code}
> loki (09:37) 259/0 $ nghttp -v -u http://docs.trafficserver.apache.org
> [  0.031] Connected
> [  0.031] HTTP Upgrade request
> GET / HTTP/1.1
> Host: docs.trafficserver.apache.org
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c-14
> HTTP2-Settings: AAMAAABkAAQAAP__
> Accept: */*
> User-Agent: nghttp2/0.7.4-DEV
> [  0.066] HTTP Upgrade response
> HTTP/1.1 101 Switching Protocols
> Date: Sun, 05 Apr 2015 15:37:58 GMT
> Connection: Upgrade
> Via: http/1.1 ATS (ApacheTrafficServer/5.3.0 [c s f ])
> Server: ATS/5.3.0
> Upgrade: h2c-14
> [  0.066] HTTP Upgrade success
> [  0.066] recv SETTINGS frame 

[jira] [Updated] (TS-3968) Remove dead ink_auth_api code

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3968:
--
Summary: Remove dead ink_auth_api code  (was: remove dead ink_auth_api code)

> Remove dead ink_auth_api code
> -
>
> Key: TS-3968
> URL: https://issues.apache.org/jira/browse/TS-3968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup
>Reporter: James Peach
>Assignee: James Peach
>Priority: Trivial
> Fix For: 6.1.0
>
>
> The code in {{ink_auth_api.h}} and {{ink_auth_api.cc}} is never used. 
> Removing it.



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

[jira] [Updated] (TS-3997) Disable h2c upgrades (for now)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3997:
--
Fix Version/s: (was: 6.1.0)

> Disable h2c upgrades (for now)
> --
>
> Key: TS-3997
> URL: https://issues.apache.org/jira/browse/TS-3997
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>
> Prioritizes the responses back to the client based on the priority level 
> specified by the HTTP/2 protocol.



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

[jira] [Updated] (TS-3821) Segmentation fault possibly due leaks in atscppapi

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3821:
--
Fix Version/s: (was: 6.1.0)

> Segmentation fault possibly due leaks in atscppapi
> --
>
> Key: TS-3821
> URL: https://issues.apache.org/jira/browse/TS-3821
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: Jiri Podhorsky
>Assignee: Brian Geffon
> Attachments: AlwaysCache.cc, BlockIP.cc, EditHeader.cc
>
>
> Hello,
> I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled 
> plugins in atscppapi, in which are used other Plugins than GlobalPlugin 
> (TransformationPlugin, InterceptionPlugin,...)
> i'm building traffic server only with parameters:
> ./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver 
> --enable-cppapi
> I'm getting segfault:
> {noformat}
> traffic_server: Segmentation fault (Address not mapped to object [(nil)])
> traffic_server - STACK TRACE: 
> /www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
> {noformat}
> I tried to find an Issue and found possible leak in dectructor ~Transaction() 
>  of Transaction.cc file.
> The leak is, there is added plugin by addPlugin(TransactionPlugin *);
> and according to documentation 
> [https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
>  Transaction should be responsible for cleaning.
> But nothing removes items of list state_.plugins_, where should be pointers 
> to memory allocated with new, which won't be deleted by delete state_;
> I tried to correct it with
> {noformat} 
> for (TransactionPlugin* tmp : state_->plugins_) {
>   delete tmp;
> }
> {noformat}
> But it didn't work. I'm getting similar segfault with another 
> {noformat}
> traffic_server: Segmentation fault (Invalid permissions for mapped object 
> [0x2b86141ea898])
> traffic_server - STACK TRACE: 
> /www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
> [0x2b86141ea898]
> {noformat}
> I tried to find more deep and find the plugins should be freed by delete in 
> another class in file utils_internal.cc.
> But if this is true, I should see in debug mode message, which is printed 
> before delete:
> {noformat}
> LOG_DEBUG("Locked Mutex...Deleting transaction plugin at %p", *iter);
> {noformat}
> But I don't see such messages in log.
> I can see in error.log lot of these messages. I'm getting them at least every 
> second.
> {noformat}
> 20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server 
> request already initialized
> {noformat}
> Can you help me find the issue? Thanks for help in advance.



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

[jira] [Updated] (TS-3809) Corrupt debug log messages LogFormat::parse_format_string

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3809:
--
Fix Version/s: (was: 6.1.0)

> Corrupt debug log messages LogFormat::parse_format_string
> -
>
> Key: TS-3809
> URL: https://issues.apache.org/jira/browse/TS-3809
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 5.3.0
>Reporter: David Carlin
>Assignee: Alan M. Carroll
>  Labels: yahoo
>
> Reporting this in case its indicative of a problem.  When I start ATS 5.3.0 I 
> see these debug messages with unprintable characters:
> Maybe related to TS-2375 ?
> {code}
> Jul 31 19:46:18.982] Server {0x2ad2e4364be0} DEBUG: (log-format) 
> LogFormat::parse_format_string: field_count=12, 
> "cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct", "� � � �/� � � � 
> � �/� �"
> [Jul 31 19:46:18.982] Server {0x2ad2e4364be0} DEBUG: (log-format) 
> LogFormat::parse_format_string: field_count=6, 
> "chi,caun,cqtn,cqtx,pssc,pscl", "� - � [�] "�" � �"
> [Jul 31 19:46:18.982] Server {0x2ad2e4364be0} DEBUG: (log-format) 
> LogFormat::parse_format_string: field_count=15, 
> "chi,caun,cqtn,cqtx,pssc,pscl,sssc,sscl,cqbl,pqbl,cqhl,pshl,pqhl,sshl,tts", 
> "� - � [�] "�" � � � � � � � � � � �"
> [Jul 31 19:46:18.983] Server {0x2ad2e4364be0} DEBUG: (log-format) 
> LogFormat::parse_format_string: field_count=19, 
> "chi,caun,cqtn,cqtx,pssc,pscl,sssc,sscl,cqbl,pqbl,cqhl,pshl,pqhl,sshl,tts,phr,cfsc,pfsc,crc",
>  "� - � [�] "�" � � � � � � � � � � � � � � �"
> [Jul 31 19:46:18.983] Server {0x2ad2e4364be0} DEBUG: (log-format) 
> LogFormat::parse_format_string: field_count=13, 
> "cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct,cquuc", "� � � � � 
> � � � � �/� � � f1 f2 f3 f4"
> {code}



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

[jira] [Updated] (TS-3957) core dump from SpdyClientSession::state_session_start

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3957:
--
Summary: core dump from SpdyClientSession::state_session_start  (was: Core 
dump from SpdyClientSession::state_session_start)

> core dump from SpdyClientSession::state_session_start
> -
>
> Key: TS-3957
> URL: https://issues.apache.org/jira/browse/TS-3957
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> We see this in production on machines under swap, so the timings are very 
> distorted.
> {code}
> gdb) bt
> #0  0x in ?? ()
> #1  0x0064a5dc in SpdyClientSession::state_session_start 
> (this=0x2b234fbe8030)
> at SpdyClientSession.cc:211
> #2  0x00510e34 in Continuation::handleEvent (this=0x2b234fbe8030, 
> event=1, 
> data=0x2b23eda76630) at ../iocore/eventsystem/I_Continuation.h:145
> #3  0x0079a066 in EThread::process_event (this=0x2b21170a2010, 
> e=0x2b23eda76630, 
> calling_code=1) at UnixEThread.cc:128
> #4  0x0079a234 in EThread::execute (this=0x2b21170a2010) at 
> UnixEThread.cc:179
> #5  0x00799611 in spawn_thread_internal (a=0x12226a0) at Thread.cc:85
> #6  0x2b21153e19d1 in start_thread () from /lib64/libpthread.so.0
> #7  0x003827ee88fd in clone () from /lib64/libc.so.6
> {code}
> After poking around on the core some more [~amc] and I determined that the vc 
> referenced by the SpdyClientSession was a freed object (the vtable pointer 
> was swizzled out to be the freelist next pointer).
> We assume that the swapping is causing very odd event timing.  We replaced 
> the schedule_immediate with a direct call that that seemed to solve our crash 
> in production.



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

[jira] [Updated] (TS-3958) HTTP/2 core dump with NULL FetchSM

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3958:
--
Summary: HTTP/2 core dump with NULL FetchSM  (was: HTTP/2 coredump with 
NULL FetchSM)

> HTTP/2 core dump with NULL FetchSM
> --
>
> Key: TS-3958
> URL: https://issues.apache.org/jira/browse/TS-3958
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.1, 6.1.0
>
>
> {code}
> (gdb) bt
> #0  0x005107b0 in FetchSM::ext_get_user_data (this=0x0) at 
> FetchSM.cc:689
> #1  0x0064552e in Http2ConnectionState::send_data_frame 
> (this=0x2b940b27ac30, fetch_sm=0x0) at Http2ConnectionState.cc:891
> #2  0x00645250 in Http2ConnectionState::restart_streams 
> (this=0x2b940b27ac30) at Http2ConnectionState.cc:845
> #3  0x0064437a in rcv_window_update_frame (cs=..., cstate=..., 
> frame=...) at Http2ConnectionState.cc:539
> #4  0x00644de5 in Http2ConnectionState::main_event_handler 
> (this=0x2b940b27ac30, event=2253, edata=0x2b931ca087e0) at 
> Http2ConnectionState.cc:733
> #5  0x00510f78 in Continuation::handleEvent (this=0x2b940b27ac30, 
> event=2253, data=0x2b931ca087e0) at ../iocore/eventsystem/I_Continuation.h:150
> #6  0x0063f655 in send_connection_event (cont=0x2b940b27ac30, 
> event=2253, edata=0x2b931ca087e0) at Http2ClientSession.cc:59
> #7  0x006415e7 in Http2ClientSession::state_complete_frame_read 
> (this=0x2b940b27a9d0, event=100, edata=0x2b949c39b438) at 
> Http2ClientSession.cc:398
> #8  0x006403bd in Http2ClientSession::main_event_handler 
> (this=0x2b940b27a9d0, event=100, edata=0x2b949c39b438) at 
> Http2ClientSession.cc:222
> #9  0x00510f78 in Continuation::handleEvent (this=0x2b940b27a9d0, 
> event=100, data=0x2b949c39b438) at ../iocore/eventsystem/I_Continuation.h:150
> #10 0x0064132f in Http2ClientSession::state_start_frame_read 
> (this=0x2b940b27a9d0, event=100, edata=0x2b949c39b438) at 
> Http2ClientSession.cc:371
> #11 0x006403bd in Http2ClientSession::main_event_handler 
> (this=0x2b940b27a9d0, event=100, edata=0x2b949c39b438) at 
> Http2ClientSession.cc:222
> #12 0x00510f78 in Continuation::handleEvent (this=0x2b940b27a9d0, 
> event=100, data=0x2b949c39b438) at ../iocore/eventsystem/I_Continuation.h:150
> #13 0x00779f9e in read_signal_and_update (event=100, 
> vc=0x2b949c39b320) at UnixNetVConnection.cc:148
> #14 0x0077ce08 in UnixNetVConnection::readSignalAndUpdate 
> (this=0x2b949c39b320, event=100) at UnixNetVConnection.cc:1020
> #15 0x00761b45 in SSLNetVConnection::net_read_io 
> (this=0x2b949c39b320, nh=0x2b93165858f0, lthread=0x2b9316582010) at 
> SSLNetVConnection.cc:587
> #16 0x00773a72 in NetHandler::mainNetEvent (this=0x2b93165858f0, 
> event=5, e=0x3053270) at UnixNet.cc:547
> #17 0x00510f78 in Continuation::handleEvent (this=0x2b93165858f0, 
> event=5, data=0x3053270) at ../iocore/eventsystem/I_Continuation.h:150
> #18 0x0079ae6a in EThread::process_event (this=0x2b9316582010, 
> e=0x3053270, calling_code=5) at UnixEThread.cc:128
> #19 0x0079b374 in EThread::execute (this=0x2b9316582010) at 
> UnixEThread.cc:252
> #20 0x0079a415 in spawn_thread_internal (a=0x2f209e0) at Thread.cc:85
> #21 0x2b9313db39d1 in start_thread () from /lib64/libpthread.so.0
> #22 0x0034884e88fd in clone () from /lib64/libc.so.6
> (gdb) frame 1
> #1  0x0064552e in Http2ConnectionState::send_data_frame 
> (this=0x2b940b27ac30, fetch_sm=0x0) at Http2ConnectionState.cc:891
> 891   in Http2ConnectionState.cc
> (gdb) p fetch_sm
> $24 = (FetchSM *) 0x0
> (gdb) frame 2
> #2  0x00645250 in Http2ConnectionState::restart_streams 
> (this=0x2b940b27ac30) at Http2ConnectionState.cc:845
> 845   in Http2ConnectionState.cc
> (gdb) p *this
> $21 = { = { = {_vptr.force_VFPT_to_top = 
> 0x7ddbf0}, handler = (int (Continuation::*)(Continuation *, int,
> void *)) 0x644ac6 , 
> mutex = {m_ptr = 0x2b94042f0d50}, link = { = {next = 
> 0x0},
>   prev = 0x0}, debug_override = false}, ua_session = 0x2b940b27a9d0, 
> local_dynamic_table = 0x2b940f50cda0, remote_dynamic_table = 0x2b940c780fc0,
>   server_settings = {settings = {4096, 0, 100, 1048576, 16384, 4294967295}}, 
> client_settings = {settings = {4096, 0, 100, 65535, 16384, 4294967295}},
>   client_rwnd = 11398558, server_rwnd = 1048576, stream_list = {head = 
> 0x2b940f473fd0}, latest_streamid = 77, client_streams_count = 28, 
> continued_stream_id = 0,
>   continued_buffer = {iov_base = 0x0, iov_len = 0}}
> (gdb) p s
> $22 = (Http2Stream *) 0x2b940cd46a20
> (gdb) p *s
> $23 = {client_rwnd = 65535, server_rwnd = 1048576, link = 
> 

[jira] [Updated] (TS-3956) header_rewrite applies strange logic with = operator and whitespace

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3956:
--
Summary: header_rewrite applies strange logic with = operator and 
whitespace  (was: Header_rewrite applies strange logic with = operator and 
whitespace)

> header_rewrite applies strange logic with = operator and whitespace
> ---
>
> Key: TS-3956
> URL: https://issues.apache.org/jira/browse/TS-3956
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.1.0
>
>
> It appears that whitespace causes weird behavior with header_rewrite, for 
> example:
> If you remove the white space before the = and the quotes it appears to 
> behave correctly. This whitespace issue is likely to cause strange bugs and 
> needs to be fixed.
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> cond %{CLIENT-HEADER:Host} /^localhost$/ [AND]
> cond %{CLIENT-HEADER:non_existent_header} = "shouldnt_exist_anyway" [AND]
> add-header X-HeaderRewriteApplied true
> {code}
> With the following request:
> {code}
> curl -v localhost/
> {code}
> Header_rewrite will incorrectly apply the rule:
> {code}
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Building 
> resources, hook=TS_HTTP_READ_REQUEST_HDR_HOOK
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)  Adding 
> TXN client request header buffers
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: Host, field_loc: 0x7fffd02070d0
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Appending HEADER(Host) to evaluation value -> localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Test 
> regular expression ^localhost$ : localhost
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Successfully found regular expression match
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER(): localhost - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) Getting 
> Header: non_existent_header, field_loc: (nil)
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> Evaluating HEADER():  - rval: 1
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite) 
> OperatorAddHeader::exec() invoked on header X-HeaderRewriteApplied: true
> [Oct  4 20:56:49.245] Server {0x761b5700} DIAG: (header_rewrite)
> Adding header X-HeaderRewriteApplied
> {code}



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

[jira] [Updated] (TS-3970) Core in PluginVC

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3970:
--
Fix Version/s: (was: 6.1.0)

> Core in PluginVC
> 
>
> Key: TS-3970
> URL: https://issues.apache.org/jira/browse/TS-3970
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Labels: crash
> Attachments: ts-3970.diff
>
>
> One of our plugins moving from 5.0.1 to 5.3.x (plus 6.0 backports) started 
> seeing the following stack trace with high frequency.
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 0x0054c232 in PluginVC::process_read_side (this=0x2b9ace2f3850, 
> other_side_call=true) at PluginVC.cc:638
> in PluginVC.cc
> #0 0x0054c232 in PluginVC::process_read_side (this=0x2b9ace2f3850, 
> other_side_call=true) at PluginVC.cc:638
> #1 0x0054be2a in PluginVC::process_write_side (this=0x2b9ace2f3a40, 
> other_side_call=false) at PluginVC.cc:555
> #2 0x0054acdb in PluginVC::main_handler (this=0x2b9ace2f3a40, 
> event=1, data=0x2b9b1e32e930) at PluginVC.cc:208
> #3 0x00510c84 in Continuation::handleEvent (this=0x2b9ace2f3a40, 
> event=1, data=0x2b9b1e32e930) at ../iocore/eventsystem/I_Continuation.h:145
> #4 0x0079a2a6 in EThread::process_event (this=0x2b9ab63d9010, 
> e=0x2b9b1e32e930, calling_code=1) at UnixEThread.cc:128
> #5 0x0079a474 in EThread::execute (this=0x2b9ab63d9010) at 
> UnixEThread.cc:179
> #6 0x00799851 in spawn_thread_internal (a=0x2fea360) at Thread.cc:85
> #7 0x2b9ab457e9d1 in start_thread () from /lib64/libpthread.so.0
> #8 0x0030d38e88fd in clone () from /lib64/libc.so.6
> {code}
> The output buffer fetched by PluginVC::process_read_side was NULL.
> I think they reason this appears in 5.3 is due to the fix for TS-3522.  
> Before that change only one do_io_read was made very early to set up the read 
> from server.  This bug fix delays the real read to later and pulls mbuf out 
> of server_buffer_reader. In some cases for this plugin, the mbuf is NULL by 
> the time we get there.
> I fixed the core by using server_session->read_buffer in the do_io_read 
> instead of server_buffer_reader->mbuf.  This seems to fix the problem.



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

[jira] [Updated] (TS-3961) Open source Yahoo's ats-multiplexer plug-in

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3961:
--
Issue Type: New Feature  (was: Task)

> Open source Yahoo's ats-multiplexer plug-in
> ---
>
> Key: TS-3961
> URL: https://issues.apache.org/jira/browse/TS-3961
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Daniel Vitor Morilha
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Open source Yahoo's ats-multiplexer plug-in through a PR. Please send me 
> instructions, if any.



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

[jira] [Commented] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[ASF subversion and git services (JIRA)]

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

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

Commit abeb61b36caf3c4970eb83e497c70c2b61ac9cff in trafficserver's branch 
refs/heads/6.1.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=abeb61b ]

TS-4081 Adds --pristine to use pristine URL on escalation

This closes #418

(cherry picked from commit e393e68cc83e66d3a430f850cb113fb2e5b4dde8)


> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



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

[jira] [Updated] (TS-4029) Remove _strlen() and _memcpy()

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4029:
--
Summary: Remove _strlen() and _memcpy()  (was: remove _strlen() and 
_memcpy())

> Remove _strlen() and _memcpy()
> --
>
> Key: TS-4029
> URL: https://issues.apache.org/jira/browse/TS-4029
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> Possibly for historical reasons, there are various copies of {{_strlen}} and 
> {{_memcpy}}. Let's remove these, they are pointless.



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

[jira] [Updated] (TS-4035) Simple plugin code is wrong

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4035:
--
Summary: Simple plugin code is wrong  (was: SImple plugin code is wrong)

> Simple plugin code is wrong
> ---
>
> Key: TS-4035
> URL: https://issues.apache.org/jira/browse/TS-4035
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Joseph Hindin
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> The simple plugin code, presented in the [plugin development 
> documentation|https://trafficserver.readthedocs.org/en/latest/developer-guide/plugins/getting-started/plugin-registration-and-version-checking.en.html]
>  , contains the following code snippet:
> {code:title=hello-world.c}
> if (!TSPluginRegister())  {
>  TSError ("[plugin_name] Plugin registration failed.");
> } 
> {code}
> But the header file defines the return code in the following way:
> {code:title=ts/apidef.h}
> typedef enum { TS_ERROR = -1, TS_SUCCESS = 0 } TSReturnCode;
> {code}
> Apparently, in case of success the return code is 0 and non-zero in case of 
> failure, so the sample code is expected to be
> {code:title=hello-world.c suggested fix for condition}
> if (TSPluginRegister())  {
>  TSError ("[plugin_name] Plugin registration failed.");
> } 
> {code}
> Also, it seems that on error {{TSPlugInit}} function should return 
> immediately, like in the following suggestion:
> {code:title=hello-world.c suggested fix}
> if (TSPluginRegister())  {
>  TSError ("[plugin_name] Plugin registration failed.");
>  return;
> } 
> {code}



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

[jira] [Updated] (TS-4031) Update docs to show new log fields

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4031:
--
Fix Version/s: (was: 6.1.0)
   Docs

> Update docs to show new log fields
> --
>
> Key: TS-4031
> URL: https://issues.apache.org/jira/browse/TS-4031
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: Docs
>
>
> Lost some log fields a few weeks ago in an update. Need to get them back. 
> Feel free to assign this to me.



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

[jira] [Updated] (TS-4031) Update docs to show new log fields

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4031:
--
Issue Type: Improvement  (was: Bug)

> Update docs to show new log fields
> --
>
> Key: TS-4031
> URL: https://issues.apache.org/jira/browse/TS-4031
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: Docs
>
>
> Lost some log fields a few weeks ago in an update. Need to get them back. 
> Feel free to assign this to me.



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

[jira] [Updated] (TS-4023) cachekey plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4023:
--
Issue Type: New Feature  (was: Improvement)

> cachekey plugin
> ---
>
> Key: TS-4023
> URL: https://issues.apache.org/jira/browse/TS-4023
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Cache
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 6.1.0
>
>
> This plugin allows some common cache key normalizations of the URI.  It can
> - sort query parameters so reordering can be a cache hit
> - ignore specific query parameters from the cache key by name or regular 
> expression
> - ignore all query parameters from the cache key
> - only use specific query parameters in the cache key by name or regular 
> expression
> - include headers or cookies by name
> - capture / replace values from the User-Agent header.
> - classify request using User-Agent and a list of regular expressions



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

[jira] [Updated] (TS-4126) Crash with high concurrency and low max_connections_active_in

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-4126:
---
Fix Version/s: 6.0.1

> Crash with high concurrency and low max_connections_active_in
> -
>
> Key: TS-4126
> URL: https://issues.apache.org/jira/browse/TS-4126
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Luca Bruno
> Fix For: 6.0.1
>
>
> ATS 6.0.0 reproducible crash with high concurrency (thousands of connections) 
> and low proxy.config.net.max_connections_active_in.
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x71062700 (LWP 51041)]
> NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> 678   UnixNet.cc: No such file or directory.
> (gdb) bt
> #0  NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> #1  0x55891383 in NetHandler::manage_active_queue 
> (this=0x72076b90) at UnixNet.cc:590
> #2  0x5589143a in NetHandler::add_to_active_queue 
> (this=0x72076b90, vc=0x7fffe4048f40) at UnixNet.cc:720
> #3  0x556dd82d in HttpClientSession::new_transaction 
> (this=0x7fffcc0ac1d0) at HttpClientSession.cc:124
> #4  0x55666d67 in ProxyClientSession::state_api_callout 
> (this=0x7fffcc0ac1d0, event=) at ProxyClientSession.cc:123
> #5  0x556de75b in HttpClientSession::new_connection 
> (this=0x7fffcc0ac1d0, new_vc=, iobuf=, 
> reader=, backdoor=)
> at HttpClientSession.cc:220
> #6  0x556d860d in HttpSessionAccept::accept (this=, 
> netvc=0x7fffe4048f40, iobuf=, reader=0x7fffa4021a68) at 
> HttpSessionAccept.cc:74
> #7  0x556668ab in ProtocolProbeTrampoline::ioCompletionEvent 
> (this=0x7fffb002d8d0, event=1, edata=0x71062a30) at 
> ProtocolProbeSessionAccept.cc:123
> #8  0x5589bf19 in handleEvent (data=0x7fffe4049060, event= out>, this=) at ../../iocore/eventsystem/I_Continuation.h:146
> #9  read_signal_and_update (event=, vc=0x7fffe4048f40) at 
> UnixNetVConnection.cc:145
> #10 0x558a080c in read_from_net (nh=0x72076b90, 
> vc=0x7fffe4048f40, thread=0x72073010) at UnixNetVConnection.cc:377
> #11 0x5588f33a in NetHandler::mainNetEvent (this=0x72076b90, 
> event=1, e=0x71062a30) at UnixNet.cc:516
> #12 0x558c352b in handleEvent (data=0x562b5820, event=5, 
> this=0x72076b90) at I_Continuation.h:146
> #13 EThread::process_event (this=this@entry=0x72073010, e=0x562b5820, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> #14 0x558c4e26 in EThread::execute (this=0x72073010) at 
> UnixEThread.cc:252
> #15 0x558c2eae in spawn_thread_internal (a=0x5620cf90) at 
> Thread.cc:86
> #16 0x760510a4 in start_thread (arg=0x71062700) at 
> pthread_create.c:309
> #17 0x74ff904d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {noformat}
> To reproduce:
> 1. Set proxy.config.net.max_connections_active_in to 100
> 2. ab -c 2 -n 10 http://sameurlhere



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

[jira] [Commented] (TS-4126) Crash with high concurrency and low max_connections_active_in

[Luca Bruno (JIRA)]

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

Luca Bruno commented on TS-4126:


Seems like the keep_alive_queue is empty, yet keep_alive_queue.head is accessed 
unconditionally. The debug says this right before crashing:

{noformat}
[Jan 12 15:06:01.082] Server {0x70d5f700} DEBUG:  (net_queue) closing connection NetVC=0x7fff30016df0 idle: 0 now: 
1452607561 at: 0 in: 30 diff: 1452607591
{noformat}

As you can see, idle: 0, which is keep_alive_queue_size. In fact the crash path 
is at keep_alive_queue.head->handleEvent(EVENT_IMMEDIATE, ); .


> Crash with high concurrency and low max_connections_active_in
> -
>
> Key: TS-4126
> URL: https://issues.apache.org/jira/browse/TS-4126
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Luca Bruno
>
> ATS 6.0.0 reproducible crash with high concurrency (thousands of connections) 
> and low proxy.config.net.max_connections_active_in.
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x71062700 (LWP 51041)]
> NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> 678   UnixNet.cc: No such file or directory.
> (gdb) bt
> #0  NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> #1  0x55891383 in NetHandler::manage_active_queue 
> (this=0x72076b90) at UnixNet.cc:590
> #2  0x5589143a in NetHandler::add_to_active_queue 
> (this=0x72076b90, vc=0x7fffe4048f40) at UnixNet.cc:720
> #3  0x556dd82d in HttpClientSession::new_transaction 
> (this=0x7fffcc0ac1d0) at HttpClientSession.cc:124
> #4  0x55666d67 in ProxyClientSession::state_api_callout 
> (this=0x7fffcc0ac1d0, event=) at ProxyClientSession.cc:123
> #5  0x556de75b in HttpClientSession::new_connection 
> (this=0x7fffcc0ac1d0, new_vc=, iobuf=, 
> reader=, backdoor=)
> at HttpClientSession.cc:220
> #6  0x556d860d in HttpSessionAccept::accept (this=, 
> netvc=0x7fffe4048f40, iobuf=, reader=0x7fffa4021a68) at 
> HttpSessionAccept.cc:74
> #7  0x556668ab in ProtocolProbeTrampoline::ioCompletionEvent 
> (this=0x7fffb002d8d0, event=1, edata=0x71062a30) at 
> ProtocolProbeSessionAccept.cc:123
> #8  0x5589bf19 in handleEvent (data=0x7fffe4049060, event= out>, this=) at ../../iocore/eventsystem/I_Continuation.h:146
> #9  read_signal_and_update (event=, vc=0x7fffe4048f40) at 
> UnixNetVConnection.cc:145
> #10 0x558a080c in read_from_net (nh=0x72076b90, 
> vc=0x7fffe4048f40, thread=0x72073010) at UnixNetVConnection.cc:377
> #11 0x5588f33a in NetHandler::mainNetEvent (this=0x72076b90, 
> event=1, e=0x71062a30) at UnixNet.cc:516
> #12 0x558c352b in handleEvent (data=0x562b5820, event=5, 
> this=0x72076b90) at I_Continuation.h:146
> #13 EThread::process_event (this=this@entry=0x72073010, e=0x562b5820, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> #14 0x558c4e26 in EThread::execute (this=0x72073010) at 
> UnixEThread.cc:252
> #15 0x558c2eae in spawn_thread_internal (a=0x5620cf90) at 
> Thread.cc:86
> #16 0x760510a4 in start_thread (arg=0x71062700) at 
> pthread_create.c:309
> #17 0x74ff904d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {noformat}
> To reproduce:
> 1. Set proxy.config.net.max_connections_active_in to 100
> 2. ab -c 2 -n 10 http://sameurlhere



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

[jira] [Resolved] (TS-4126) Crash with high concurrency and low max_connections_active_in

[Luca Bruno (JIRA)]

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

Luca Bruno resolved TS-4126.

Resolution: Duplicate

I've realized this has been fixed. Thanks.

> Crash with high concurrency and low max_connections_active_in
> -
>
> Key: TS-4126
> URL: https://issues.apache.org/jira/browse/TS-4126
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Luca Bruno
>
> ATS 6.0.0 reproducible crash with high concurrency (thousands of connections) 
> and low proxy.config.net.max_connections_active_in.
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x71062700 (LWP 51041)]
> NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> 678   UnixNet.cc: No such file or directory.
> (gdb) bt
> #0  NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> #1  0x55891383 in NetHandler::manage_active_queue 
> (this=0x72076b90) at UnixNet.cc:590
> #2  0x5589143a in NetHandler::add_to_active_queue 
> (this=0x72076b90, vc=0x7fffe4048f40) at UnixNet.cc:720
> #3  0x556dd82d in HttpClientSession::new_transaction 
> (this=0x7fffcc0ac1d0) at HttpClientSession.cc:124
> #4  0x55666d67 in ProxyClientSession::state_api_callout 
> (this=0x7fffcc0ac1d0, event=) at ProxyClientSession.cc:123
> #5  0x556de75b in HttpClientSession::new_connection 
> (this=0x7fffcc0ac1d0, new_vc=, iobuf=, 
> reader=, backdoor=)
> at HttpClientSession.cc:220
> #6  0x556d860d in HttpSessionAccept::accept (this=, 
> netvc=0x7fffe4048f40, iobuf=, reader=0x7fffa4021a68) at 
> HttpSessionAccept.cc:74
> #7  0x556668ab in ProtocolProbeTrampoline::ioCompletionEvent 
> (this=0x7fffb002d8d0, event=1, edata=0x71062a30) at 
> ProtocolProbeSessionAccept.cc:123
> #8  0x5589bf19 in handleEvent (data=0x7fffe4049060, event= out>, this=) at ../../iocore/eventsystem/I_Continuation.h:146
> #9  read_signal_and_update (event=, vc=0x7fffe4048f40) at 
> UnixNetVConnection.cc:145
> #10 0x558a080c in read_from_net (nh=0x72076b90, 
> vc=0x7fffe4048f40, thread=0x72073010) at UnixNetVConnection.cc:377
> #11 0x5588f33a in NetHandler::mainNetEvent (this=0x72076b90, 
> event=1, e=0x71062a30) at UnixNet.cc:516
> #12 0x558c352b in handleEvent (data=0x562b5820, event=5, 
> this=0x72076b90) at I_Continuation.h:146
> #13 EThread::process_event (this=this@entry=0x72073010, e=0x562b5820, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> #14 0x558c4e26 in EThread::execute (this=0x72073010) at 
> UnixEThread.cc:252
> #15 0x558c2eae in spawn_thread_internal (a=0x5620cf90) at 
> Thread.cc:86
> #16 0x760510a4 in start_thread (arg=0x71062700) at 
> pthread_create.c:309
> #17 0x74ff904d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {noformat}
> To reproduce:
> 1. Set proxy.config.net.max_connections_active_in to 100
> 2. ab -c 2 -n 10 http://sameurlhere



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

[jira] [Commented] (TS-4107) proxy.process.ssl.total_success_handshake_count_in has wrong record type

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4107:


Github user shinrich commented on the pull request:

https://github.com/apache/trafficserver/pull/409#issuecomment-170926550
  
Looks good to me.  It wasn't clear to me how to do the generated metric 
when I was originally fixing up the names, so I no doubt messed it up.


> proxy.process.ssl.total_success_handshake_count_in has wrong record type
> 
>
> Key: TS-4107
> URL: https://issues.apache.org/jira/browse/TS-4107
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{proxy.process.ssl.total_success_handshake_count_in}} is the only SSL metric 
> registered in {{RecordsConfig.cc}} where it is incorrectly registered as a 
> node metric, rather than a process metric.



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

[jira] [Commented] (TS-4104) wrong return value while create a new ticket on ssl_callback_session_ticket()

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4104:


[~zwoop]  It would be nice to get this into the 6.1.0 release.  I will run a 
test and see what I can find.

> wrong return value while create a new ticket on ssl_callback_session_ticket()
> -
>
> Key: TS-4104
> URL: https://issues.apache.org/jira/browse/TS-4104
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> from openssl online document: 
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_tlsext_ticket_key_cb.html
> The return value of the cb function is used by OpenSSL to determine what 
> further processing will occur. The following return values have meaning:
> 2
> This indicates that the ctx and hctx have been set and the session can 
> continue on those parameters. Additionally it indicates that the session 
> ticket is in a renewal period and should be replaced. The OpenSSL library 
> will call cb again with an enc argument of 1 to set the new ticket (see 
> RFC5077 3.3 paragraph 2).
> 1
> This indicates that the ctx and hctx have been set and the session can 
> continue on those parameters.
> 0
> This indicates that it was not possible to set/retrieve a session ticket and 
> the SSL/TLS session will continue by by negotiating a set of cryptographic 
> parameters or using the alternate SSL/TLS resumption mechanism, session ids.
> If called with enc equal to 0 the library will call the cb again to get a new 
> set of parameters.
> less than 0
> This indicates an error.
> {code}
> 1948   if (enc == 1) {
> 1949 const ssl_ticket_key_t _recent_key = keyblock->keys[0];
> 1950 memcpy(keyname, most_recent_key.key_name, 
> sizeof(most_recent_key.key_name));
> 1951 RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
> 1952 EVP_EncryptInit_ex(cipher_ctx, EVP_aes_128_cbc(), NULL, 
> most_recent_key.aes_key, iv);
> 1953 HMAC_Init_ex(hctx, most_recent_key.hmac_secret, 
> sizeof(most_recent_key.hmac_secret), evp_md_func, NULL);
> 1954 
> 1955 Debug("ssl", "create ticket for a new session.");
> 1956 SSL_INCREMENT_DYN_STAT(ssl_total_tickets_created_stat);
> 1957 return 0;
> 1958   } else if (enc == 0) {
> {code}
> the ssl_callback_session_ticket() should return 1 after create a new ticket 
> but 0 here.
> and the traffic.out log for current ATS release:
> {code}
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) create ticket for 
> a new session.
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 32 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8194 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) trace=FALSE
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) SSL server 
> handshake completed successfully
> {code}
> the traffic.out log if return 1 here:
> {code}
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) create ticket for 
> a new session.
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) trace=FALSE
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) SSL server 
> handshake completed successfully
> {code}



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

[jira] [Commented] (TS-4106) Cache Inspector fails to split multiline URLs

[ASF subversion and git services (JIRA)]

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

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

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

TS-4106 Allow Cache Inspector to split properly on multiline URLs

Leif: This was broken in commit bd304288b55e989, and the fixes seems
to restore original behavior (while retaining the use of strlcpy() ).

This closes #401


> Cache Inspector fails to split multiline URLs
> -
>
> Key: TS-4106
> URL: https://issues.apache.org/jira/browse/TS-4106
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Web UI
>Reporter: Hiroaki Nakamura
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
> Attachments: cache_inspector_multiline_urls_split.patch
>
>
> The error is in the length parameter at
> https://github.com/apache/trafficserver/blob/413dd51d5dc17bf388805071efdb8f882014b847/iocore/cache/CachePages.cc#L129
> Because of this error, ink_strlcpy copies strings from the current poisition 
> to the end of multiline URLs, not to the end of line.
> The attached patch cache_inspector_multiline_urls_split.patch fixes this bug.



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

[jira] [Commented] (TS-4106) Cache Inspector fails to split multiline URLs

[ASF subversion and git services (JIRA)]

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

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

Commit 19ea44d0db1ae3697f8100909f3b3b84b158c8d8 in trafficserver's branch 
refs/heads/6.1.x from [~hnakamur]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=19ea44d ]

TS-4106 Allow Cache Inspector to split properly on multiline URLs

Leif: This was broken in commit bd304288b55e989, and the fixes seems
to restore original behavior (while retaining the use of strlcpy() ).

This closes #401

(cherry picked from commit a70e9473cabba89861965d5ab775dbe4f20c720b)


> Cache Inspector fails to split multiline URLs
> -
>
> Key: TS-4106
> URL: https://issues.apache.org/jira/browse/TS-4106
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Web UI
>Reporter: Hiroaki Nakamura
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
> Attachments: cache_inspector_multiline_urls_split.patch
>
>
> The error is in the length parameter at
> https://github.com/apache/trafficserver/blob/413dd51d5dc17bf388805071efdb8f882014b847/iocore/cache/CachePages.cc#L129
> Because of this error, ink_strlcpy copies strings from the current poisition 
> to the end of multiline URLs, not to the end of line.
> The attached patch cache_inspector_multiline_urls_split.patch fixes this bug.



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

[jira] [Updated] (TS-4126) Crash with high concurrency and low max_connections_active_in

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4126:
--
Fix Version/s: (was: 6.0.1)

> Crash with high concurrency and low max_connections_active_in
> -
>
> Key: TS-4126
> URL: https://issues.apache.org/jira/browse/TS-4126
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Luca Bruno
>
> ATS 6.0.0 reproducible crash with high concurrency (thousands of connections) 
> and low proxy.config.net.max_connections_active_in.
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x71062700 (LWP 51041)]
> NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> 678   UnixNet.cc: No such file or directory.
> (gdb) bt
> #0  NetHandler::_close_vc (this=0x72076b90, vc=0x7fff40053c20, 
> now=1452601469419678969, handle_event=@0x7105da3c: 0, 
> closed=@0x7105da38: 0, total_idle_time=, 
> total_idle_count=@0x7105da44: 1) at UnixNet.cc:678
> #1  0x55891383 in NetHandler::manage_active_queue 
> (this=0x72076b90) at UnixNet.cc:590
> #2  0x5589143a in NetHandler::add_to_active_queue 
> (this=0x72076b90, vc=0x7fffe4048f40) at UnixNet.cc:720
> #3  0x556dd82d in HttpClientSession::new_transaction 
> (this=0x7fffcc0ac1d0) at HttpClientSession.cc:124
> #4  0x55666d67 in ProxyClientSession::state_api_callout 
> (this=0x7fffcc0ac1d0, event=) at ProxyClientSession.cc:123
> #5  0x556de75b in HttpClientSession::new_connection 
> (this=0x7fffcc0ac1d0, new_vc=, iobuf=, 
> reader=, backdoor=)
> at HttpClientSession.cc:220
> #6  0x556d860d in HttpSessionAccept::accept (this=, 
> netvc=0x7fffe4048f40, iobuf=, reader=0x7fffa4021a68) at 
> HttpSessionAccept.cc:74
> #7  0x556668ab in ProtocolProbeTrampoline::ioCompletionEvent 
> (this=0x7fffb002d8d0, event=1, edata=0x71062a30) at 
> ProtocolProbeSessionAccept.cc:123
> #8  0x5589bf19 in handleEvent (data=0x7fffe4049060, event= out>, this=) at ../../iocore/eventsystem/I_Continuation.h:146
> #9  read_signal_and_update (event=, vc=0x7fffe4048f40) at 
> UnixNetVConnection.cc:145
> #10 0x558a080c in read_from_net (nh=0x72076b90, 
> vc=0x7fffe4048f40, thread=0x72073010) at UnixNetVConnection.cc:377
> #11 0x5588f33a in NetHandler::mainNetEvent (this=0x72076b90, 
> event=1, e=0x71062a30) at UnixNet.cc:516
> #12 0x558c352b in handleEvent (data=0x562b5820, event=5, 
> this=0x72076b90) at I_Continuation.h:146
> #13 EThread::process_event (this=this@entry=0x72073010, e=0x562b5820, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> #14 0x558c4e26 in EThread::execute (this=0x72073010) at 
> UnixEThread.cc:252
> #15 0x558c2eae in spawn_thread_internal (a=0x5620cf90) at 
> Thread.cc:86
> #16 0x760510a4 in start_thread (arg=0x71062700) at 
> pthread_create.c:309
> #17 0x74ff904d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> {noformat}
> To reproduce:
> 1. Set proxy.config.net.max_connections_active_in to 100
> 2. ab -c 2 -n 10 http://sameurlhere



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

[jira] [Commented] (TS-4106) Cache Inspector fails to split multiline URLs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4106:


Github user asfgit closed the pull request at:

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


> Cache Inspector fails to split multiline URLs
> -
>
> Key: TS-4106
> URL: https://issues.apache.org/jira/browse/TS-4106
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Web UI
>Reporter: Hiroaki Nakamura
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
> Attachments: cache_inspector_multiline_urls_split.patch
>
>
> The error is in the length parameter at
> https://github.com/apache/trafficserver/blob/413dd51d5dc17bf388805071efdb8f882014b847/iocore/cache/CachePages.cc#L129
> Because of this error, ink_strlcpy copies strings from the current poisition 
> to the end of multiline URLs, not to the end of line.
> The attached patch cache_inspector_multiline_urls_split.patch fixes this bug.



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

[jira] [Commented] (TS-4125) wrong non-active conditions check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4125:


GitHub user oknet opened a pull request:

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

TS-4125: wrong non-active conditions check



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

$ git pull https://github.com/oknet/trafficserver patch-4

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

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

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

This closes #416


commit b45f1e2065f0545f952b047b66d69d8d50276e60
Author: Oknet 
Date:   2016-01-12T12:25:28Z

wrong non-active conditions check




> wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Updated] (TS-4104) wrong return value while create a new ticket on ssl_callback_session_ticket()

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4104:
--
Fix Version/s: (was: 6.1.0)
   6.2.0

> wrong return value while create a new ticket on ssl_callback_session_ticket()
> -
>
> Key: TS-4104
> URL: https://issues.apache.org/jira/browse/TS-4104
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Oknet Xu
> Fix For: 6.2.0
>
>
> from openssl online document: 
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_tlsext_ticket_key_cb.html
> The return value of the cb function is used by OpenSSL to determine what 
> further processing will occur. The following return values have meaning:
> 2
> This indicates that the ctx and hctx have been set and the session can 
> continue on those parameters. Additionally it indicates that the session 
> ticket is in a renewal period and should be replaced. The OpenSSL library 
> will call cb again with an enc argument of 1 to set the new ticket (see 
> RFC5077 3.3 paragraph 2).
> 1
> This indicates that the ctx and hctx have been set and the session can 
> continue on those parameters.
> 0
> This indicates that it was not possible to set/retrieve a session ticket and 
> the SSL/TLS session will continue by by negotiating a set of cryptographic 
> parameters or using the alternate SSL/TLS resumption mechanism, session ids.
> If called with enc equal to 0 the library will call the cb again to get a new 
> set of parameters.
> less than 0
> This indicates an error.
> {code}
> 1948   if (enc == 1) {
> 1949 const ssl_ticket_key_t _recent_key = keyblock->keys[0];
> 1950 memcpy(keyname, most_recent_key.key_name, 
> sizeof(most_recent_key.key_name));
> 1951 RAND_pseudo_bytes(iv, EVP_MAX_IV_LENGTH);
> 1952 EVP_EncryptInit_ex(cipher_ctx, EVP_aes_128_cbc(), NULL, 
> most_recent_key.aes_key, iv);
> 1953 HMAC_Init_ex(hctx, most_recent_key.hmac_secret, 
> sizeof(most_recent_key.hmac_secret), evp_md_func, NULL);
> 1954 
> 1955 Debug("ssl", "create ticket for a new session.");
> 1956 SSL_INCREMENT_DYN_STAT(ssl_total_tickets_created_stat);
> 1957 return 0;
> 1958   } else if (enc == 0) {
> {code}
> the ssl_callback_session_ticket() should return 1 after create a new ticket 
> but 0 here.
> and the traffic.out log for current ATS release:
> {code}
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) create ticket for 
> a new session.
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8193 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 32 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) ssl_callback_info 
> ssl: 0x2b0544006840 where: 8194 ret: 1
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) trace=FALSE
> [Dec 28 21:01:12.742] Server {0x2b052fe4b700} DEBUG: (ssl) SSL server 
> handshake completed successfully
> {code}
> the traffic.out log if return 1 here:
> {code}
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) create ticket for 
> a new session.
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) trace=FALSE
> [Dec 30 12:47:16.838] Server {0x2b6ec9340700} DEBUG: (ssl) SSL server 
> handshake completed successfully
> {code}



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

[jira] [Commented] (TS-4024) Wire tracing enhancements

[ASF subversion and git services (JIRA)]

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

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

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

[TS-4024] wire tracing enhancements.  This closes #337.


> Wire tracing enhancements
> -
>
> Key: TS-4024
> URL: https://issues.apache.org/jira/browse/TS-4024
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.2.0
>
>
> Some enhancements from Yahoo! to make wire tracing dynamically enable-able 
> and to enhance log messages.



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

[jira] [Commented] (TS-4024) Wire tracing enhancements

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4024:


Github user asfgit closed the pull request at:

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


> Wire tracing enhancements
> -
>
> Key: TS-4024
> URL: https://issues.apache.org/jira/browse/TS-4024
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.2.0
>
>
> Some enhancements from Yahoo! to make wire tracing dynamically enable-able 
> and to enhance log messages.



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

[jira] [Updated] (TS-4064) Customizable congestion control algorithms

[Brian Geffon (JIRA)]

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

Brian Geffon updated TS-4064:
-
Fix Version/s: (was: sometime)
   6.2.0

> Customizable congestion control algorithms
> --
>
> Key: TS-4064
> URL: https://issues.apache.org/jira/browse/TS-4064
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.2.0
>
>
> This ticket will track per-socket configurable congestion control algorithms 
> based on incoming or outgoing socket types / listen or connection types.
> Given asymmetric routes (such as User -> PoP -> DC) it might make sense to 
> have different congestion control algorithms or listening sockets and 
> outgoing sockets.



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

[jira] [Resolved] (TS-4064) Customizable congestion control algorithms

[Brian Geffon (JIRA)]

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

Brian Geffon resolved TS-4064.
--
Resolution: Fixed

> Customizable congestion control algorithms
> --
>
> Key: TS-4064
> URL: https://issues.apache.org/jira/browse/TS-4064
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.2.0
>
>
> This ticket will track per-socket configurable congestion control algorithms 
> based on incoming or outgoing socket types / listen or connection types.
> Given asymmetric routes (such as User -> PoP -> DC) it might make sense to 
> have different congestion control algorithms or listening sockets and 
> outgoing sockets.



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

[jira] [Commented] (TS-4064) Customizable congestion control algorithms

[ASF subversion and git services (JIRA)]

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

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

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

TS-4064: Customizable congestion control algorithms: DOCS


> Customizable congestion control algorithms
> --
>
> Key: TS-4064
> URL: https://issues.apache.org/jira/browse/TS-4064
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: sometime
>
>
> This ticket will track per-socket configurable congestion control algorithms 
> based on incoming or outgoing socket types / listen or connection types.
> Given asymmetric routes (such as User -> PoP -> DC) it might make sense to 
> have different congestion control algorithms or listening sockets and 
> outgoing sockets.



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

[jira] [Commented] (TS-4064) Customizable congestion control algorithms

[ASF subversion and git services (JIRA)]

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

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

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

TS-4064: Customizable congestion control algorithms


> Customizable congestion control algorithms
> --
>
> Key: TS-4064
> URL: https://issues.apache.org/jira/browse/TS-4064
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: sometime
>
>
> This ticket will track per-socket configurable congestion control algorithms 
> based on incoming or outgoing socket types / listen or connection types.
> Given asymmetric routes (such as User -> PoP -> DC) it might make sense to 
> have different congestion control algorithms or listening sockets and 
> outgoing sockets.



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

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF subversion and git services (JIRA)]

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

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

Commit 45266942b4510f5d06f2af95ea7b8972134ad8f8 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4526694 ]

TS-3072: Debug logging for single connection. Without config control.  This 
closes #398.


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072-config.diff, ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Resolved] (TS-4107) proxy.process.ssl.total_success_handshake_count_in has wrong record type

[James Peach (JIRA)]

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

James Peach resolved TS-4107.
-
Resolution: Fixed

> proxy.process.ssl.total_success_handshake_count_in has wrong record type
> 
>
> Key: TS-4107
> URL: https://issues.apache.org/jira/browse/TS-4107
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{proxy.process.ssl.total_success_handshake_count_in}} is the only SSL metric 
> registered in {{RecordsConfig.cc}} where it is incorrectly registered as a 
> node metric, rather than a process metric.



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

[jira] [Commented] (TS-4107) proxy.process.ssl.total_success_handshake_count_in has wrong record type

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4107:


Github user asfgit closed the pull request at:

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


> proxy.process.ssl.total_success_handshake_count_in has wrong record type
> 
>
> Key: TS-4107
> URL: https://issues.apache.org/jira/browse/TS-4107
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{proxy.process.ssl.total_success_handshake_count_in}} is the only SSL metric 
> registered in {{RecordsConfig.cc}} where it is incorrectly registered as a 
> node metric, rather than a process metric.



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

[jira] [Commented] (TS-4107) proxy.process.ssl.total_success_handshake_count_in has wrong record type

[ASF subversion and git services (JIRA)]

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

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

Commit 8e0f81454fd79cc4dde4bba17b4eb38a7f195c0d in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8e0f814 ]

TS-4107: proxy.process.ssl.total_success_handshake_count_in has wrong record 
type

proxy.process.ssl.total_success_handshake_count_in should be the
metrics generated in the core SSL code, and the old compatible name
proxy.process.ssl.total_success_handshake_count should be generated
as a custom metric. The custom metric needs to be registered in
RecordsConfig.cc but it should be of type RECT_PROCESS not RECT_NODE.

This closes #409.


> proxy.process.ssl.total_success_handshake_count_in has wrong record type
> 
>
> Key: TS-4107
> URL: https://issues.apache.org/jira/browse/TS-4107
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{proxy.process.ssl.total_success_handshake_count_in}} is the only SSL metric 
> registered in {{RecordsConfig.cc}} where it is incorrectly registered as a 
> node metric, rather than a process metric.



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

[jira] [Commented] (TS-4107) proxy.process.ssl.total_success_handshake_count_in has wrong record type

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4107:
---

[~jpe...@apache.org] do we want this in for 6.1.0 ?

> proxy.process.ssl.total_success_handshake_count_in has wrong record type
> 
>
> Key: TS-4107
> URL: https://issues.apache.org/jira/browse/TS-4107
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> {{proxy.process.ssl.total_success_handshake_count_in}} is the only SSL metric 
> registered in {{RecordsConfig.cc}} where it is incorrectly registered as a 
> node metric, rather than a process metric.



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[ASF subversion and git services (JIRA)]

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

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

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

TS-4060: add JSON support consistently for traffic_layout

This closes #417.


> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4060:


Github user asfgit closed the pull request at:

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


> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Updated] (TS-4060) traffic_layout JSON option does't always work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4060:
--
Fix Version/s: (was: 6.2.0)
   6.1.0

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF subversion and git services (JIRA)]

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

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

Commit 51faf6ee98c351a2f1b545183e463e4fcde1d38f in trafficserver's branch 
refs/heads/6.1.x from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=51faf6e ]

TS-3072: fix newer compiler warnings.

(cherry picked from commit 7cd050790b4cc6a85becebef7438e01f267f0bd3)


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072-config.diff, ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF subversion and git services (JIRA)]

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

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

Commit 230d25584fe358a3a8005766b92a5ce0a8681eac in trafficserver's branch 
refs/heads/6.1.x from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=230d255 ]

TS-3072: Debug logging for single connection. Without config control.  This 
closes #398.

(cherry picked from commit 45266942b4510f5d06f2af95ea7b8972134ad8f8)


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072-config.diff, ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[ASF subversion and git services (JIRA)]

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

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

Commit 909a7902f502e984a695cba9d98edd4a0834c841 in trafficserver's branch 
refs/heads/6.1.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=909a790 ]

TS-4060: add JSON support consistently for traffic_layout

This closes #417.

(cherry picked from commit 8261460fc1e3483a3581d5318b14033f0c986b0e)


> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-4113) Docs: Add value 4 to proxy.config.http.cache.cache_responses_to_cookies

[ASF subversion and git services (JIRA)]

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

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

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

TS-4113: add value 4 to proxy.config.http.cache.cache_responses_to_cookies

This closes #411.


> Docs: Add value 4 to proxy.config.http.cache.cache_responses_to_cookies
> ---
>
> Key: TS-4113
> URL: https://issues.apache.org/jira/browse/TS-4113
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: Jon Sime
> Fix For: 6.2.0, Docs
>
>
> Currently there are values 0 to 3 at 
> http://trafficserver.readthedocs.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-cache-cache-responses-to-cookies
> {quote}
> 0 = do not cache any responses to cookies
> 1 = cache for any content-type
> 2 = cache only for image types
> 3 = cache for all but text content-types
> {quote}
> However there are 0 to 4 values in the source code
> https://github.com/apache/trafficserver/blob/d197d75601772139ea489dc5686fd041dc3c257a/mgmt/RecordsConfig.cc#L643-L650
> {quote}
>   //   # cache responses to cookies has 4 options
>   //   #
>   //   #  0 - do not cache any responses to cookies
>   //   #  1 - cache for any content-type (ignore cookies)
>   //   #  2 - cache only for image types
>   //   #  3 - cache for all but text content-types
>   //   #  4 - cache for all but text content-types except OS response 
> without "Set-Cookie" or with "Cache-Control: public"
>   {RECT_CONFIG, "proxy.config.http.cache.cache_responses_to_cookies", 
> RECD_INT, "1", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-4]", RECA_NULL}
> {quote}
> So we should add the docs about the value 4
> 4 = cache for all but text content-types except OS response without 
> "Set-Cookie" or with "Cache-Control: public



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

[jira] [Resolved] (TS-4113) Docs: Add value 4 to proxy.config.http.cache.cache_responses_to_cookies

[James Peach (JIRA)]

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

James Peach resolved TS-4113.
-
   Resolution: Fixed
Fix Version/s: 6.2.0

> Docs: Add value 4 to proxy.config.http.cache.cache_responses_to_cookies
> ---
>
> Key: TS-4113
> URL: https://issues.apache.org/jira/browse/TS-4113
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: Jon Sime
> Fix For: 6.2.0, Docs
>
>
> Currently there are values 0 to 3 at 
> http://trafficserver.readthedocs.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-cache-cache-responses-to-cookies
> {quote}
> 0 = do not cache any responses to cookies
> 1 = cache for any content-type
> 2 = cache only for image types
> 3 = cache for all but text content-types
> {quote}
> However there are 0 to 4 values in the source code
> https://github.com/apache/trafficserver/blob/d197d75601772139ea489dc5686fd041dc3c257a/mgmt/RecordsConfig.cc#L643-L650
> {quote}
>   //   # cache responses to cookies has 4 options
>   //   #
>   //   #  0 - do not cache any responses to cookies
>   //   #  1 - cache for any content-type (ignore cookies)
>   //   #  2 - cache only for image types
>   //   #  3 - cache for all but text content-types
>   //   #  4 - cache for all but text content-types except OS response 
> without "Set-Cookie" or with "Cache-Control: public"
>   {RECT_CONFIG, "proxy.config.http.cache.cache_responses_to_cookies", 
> RECD_INT, "1", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-4]", RECA_NULL}
> {quote}
> So we should add the docs about the value 4
> 4 = cache for all but text content-types except OS response without 
> "Set-Cookie" or with "Cache-Control: public



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

[jira] [Commented] (TS-4113) Docs: Add value 4 to proxy.config.http.cache.cache_responses_to_cookies

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4113:


Github user asfgit closed the pull request at:

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


> Docs: Add value 4 to proxy.config.http.cache.cache_responses_to_cookies
> ---
>
> Key: TS-4113
> URL: https://issues.apache.org/jira/browse/TS-4113
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: Jon Sime
> Fix For: 6.2.0, Docs
>
>
> Currently there are values 0 to 3 at 
> http://trafficserver.readthedocs.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-cache-cache-responses-to-cookies
> {quote}
> 0 = do not cache any responses to cookies
> 1 = cache for any content-type
> 2 = cache only for image types
> 3 = cache for all but text content-types
> {quote}
> However there are 0 to 4 values in the source code
> https://github.com/apache/trafficserver/blob/d197d75601772139ea489dc5686fd041dc3c257a/mgmt/RecordsConfig.cc#L643-L650
> {quote}
>   //   # cache responses to cookies has 4 options
>   //   #
>   //   #  0 - do not cache any responses to cookies
>   //   #  1 - cache for any content-type (ignore cookies)
>   //   #  2 - cache only for image types
>   //   #  3 - cache for all but text content-types
>   //   #  4 - cache for all but text content-types except OS response 
> without "Set-Cookie" or with "Cache-Control: public"
>   {RECT_CONFIG, "proxy.config.http.cache.cache_responses_to_cookies", 
> RECD_INT, "1", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-4]", RECA_NULL}
> {quote}
> So we should add the docs about the value 4
> 4 = cache for all but text content-types except OS response without 
> "Set-Cookie" or with "Cache-Control: public



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

[jira] [Commented] (TS-4121) Doc: Add proxy.config.http.request_via_str

[ASF subversion and git services (JIRA)]

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

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

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

TS-4121: document proxy.config.http.request_via_str

This closes #413.
 Please enter the commit message for your changes. Lines starting


> Doc: Add proxy.config.http.request_via_str
> --
>
> Key: TS-4121
> URL: https://issues.apache.org/jira/browse/TS-4121
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
> Fix For: 6.2.0
>
>
> Add proxy.config.http.request_via_str to the document.
> I created the pull request for this issue: 
> https://github.com/apache/trafficserver/pull/413



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

[jira] [Resolved] (TS-4121) Doc: Add proxy.config.http.request_via_str

[James Peach (JIRA)]

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

James Peach resolved TS-4121.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 6.2.0

> Doc: Add proxy.config.http.request_via_str
> --
>
> Key: TS-4121
> URL: https://issues.apache.org/jira/browse/TS-4121
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> Add proxy.config.http.request_via_str to the document.
> I created the pull request for this issue: 
> https://github.com/apache/trafficserver/pull/413



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

[jira] [Commented] (TS-4120) Doc: proxy.config.http.response_server_str default value includes version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4120:


Github user asfgit closed the pull request at:

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


> Doc: proxy.config.http.response_server_str default value includes version
> -
>
> Key: TS-4120
> URL: https://issues.apache.org/jira/browse/TS-4120
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
> Fix For: 6.2.0
>
>
> The current doc says that the default value is ATS/ and the current version 
> is always appended to this string.
> Actually the default value is something like ATS/6.0.0 and the current 
> version is not appended.



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

[jira] [Resolved] (TS-4120) Doc: proxy.config.http.response_server_str default value includes version

[James Peach (JIRA)]

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

James Peach resolved TS-4120.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 6.2.0

> Doc: proxy.config.http.response_server_str default value includes version
> -
>
> Key: TS-4120
> URL: https://issues.apache.org/jira/browse/TS-4120
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> The current doc says that the default value is ATS/ and the current version 
> is always appended to this string.
> Actually the default value is something like ATS/6.0.0 and the current 
> version is not appended.



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

[jira] [Commented] (TS-4120) Doc: proxy.config.http.response_server_str default value includes version

[ASF subversion and git services (JIRA)]

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

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

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

TS-4120: proxy.config.http.response_server_str default value includes version

This closes #412.


> Doc: proxy.config.http.response_server_str default value includes version
> -
>
> Key: TS-4120
> URL: https://issues.apache.org/jira/browse/TS-4120
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
> Fix For: 6.2.0
>
>
> The current doc says that the default value is ATS/ and the current version 
> is always appended to this string.
> Actually the default value is something like ATS/6.0.0 and the current 
> version is not appended.



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

[jira] [Commented] (TS-4122) Doc: Add proxy.config.http.response_via_str

[ASF subversion and git services (JIRA)]

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

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

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

TS-4122: document proxy.config.http.response_via_str

This closes #414.


> Doc: Add proxy.config.http.response_via_str
> ---
>
> Key: TS-4122
> URL: https://issues.apache.org/jira/browse/TS-4122
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
> Fix For: 6.2.0
>
>
> Add proxy.config.http.response_via_str to the document.
> I created the pull request for this issue: 
> https://github.com/apache/trafficserver/pull/414



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

[jira] [Resolved] (TS-4122) Doc: Add proxy.config.http.response_via_str

[James Peach (JIRA)]

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

James Peach resolved TS-4122.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 6.2.0

> Doc: Add proxy.config.http.response_via_str
> ---
>
> Key: TS-4122
> URL: https://issues.apache.org/jira/browse/TS-4122
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
>Assignee: James Peach
> Fix For: 6.2.0
>
>
> Add proxy.config.http.response_via_str to the document.
> I created the pull request for this issue: 
> https://github.com/apache/trafficserver/pull/414



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

[jira] [Commented] (TS-4122) Doc: Add proxy.config.http.response_via_str

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4122:


Github user asfgit closed the pull request at:

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


> Doc: Add proxy.config.http.response_via_str
> ---
>
> Key: TS-4122
> URL: https://issues.apache.org/jira/browse/TS-4122
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs, Documentation
>Reporter: Hiroaki Nakamura
> Fix For: 6.2.0
>
>
> Add proxy.config.http.response_via_str to the document.
> I created the pull request for this issue: 
> https://github.com/apache/trafficserver/pull/414



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

[jira] [Assigned] (TS-4127) Add documentation for the escalate plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4127:
-

Assignee: Leif Hedstrom

> Add documentation for the escalate plugin
> -
>
> Key: TS-4127
> URL: https://issues.apache.org/jira/browse/TS-4127
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>




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

[jira] [Updated] (TS-4127) Add documentation for the escalate plugin

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4127:
--
Fix Version/s: Docs

> Add documentation for the escalate plugin
> -
>
> Key: TS-4127
> URL: https://issues.apache.org/jira/browse/TS-4127
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Docs
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>




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

[jira] [Created] (TS-4127) Add documentation for the escalate plugin

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4127:
-

 Summary: Add documentation for the escalate plugin
 Key: TS-4127
 URL: https://issues.apache.org/jira/browse/TS-4127
 Project: Traffic Server
  Issue Type: Improvement
  Components: Docs
Reporter: Leif Hedstrom






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

[jira] [Updated] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4081:
--
Fix Version/s: (was: 6.2.0)
   6.1.0

> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



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

[jira] [Commented] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[ASF subversion and git services (JIRA)]

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

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

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

TS-4081 Adds --pristine to use pristine URL on escalation

This closes #418


> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



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

[jira] [Commented] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4081:


Github user asfgit closed the pull request at:

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


> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



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

[jira] [Updated] (TS-3922) Add independent WebSocket timeouts

[Brian Geffon (JIRA)]

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

Brian Geffon updated TS-3922:
-
Fix Version/s: (was: sometime)
   6.2.0

> Add independent WebSocket timeouts
> --
>
> Key: TS-3922
> URL: https://issues.apache.org/jira/browse/TS-3922
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.2.0
>
>
> Right now WebSockets fall under the active/inactive transaction timeouts. 
> Obviously the inactivate timeout isn't a problem but the active timeout is. 
> We need at minimum a new timeout for active WS connections, I'll likely add a 
> new timeout for inactive state too.



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

[jira] [Updated] (TS-2118) memcached plugin is in the source tree but does not build

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2118:
--
Issue Type: Improvement  (was: Bug)

> memcached plugin is in the source tree but does not build
> -
>
> Key: TS-2118
> URL: https://issues.apache.org/jira/browse/TS-2118
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Igor Galić
>Assignee: John Rushford
>  Labels: newbie
> Fix For: 6.1.0
>
> Attachments: TS-2118.diff
>
>
> The memcached_remap plugin is currently in our experimental plugin tree, but 
> doesn't build even with {{--enable-experimental}}.
> This should be fixed.



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

[jira] [Resolved] (TS-3072) Debug logging for a single connection in production traffic.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-3072.
---
Resolution: Fixed

> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072-config.diff, ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Commented] (TS-4081) Allow escalate plugin to use the pristine URL when retrying

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4081:


GitHub user zwoop opened a pull request:

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

TS-4081 Adds --pristine to use pristine URL on escalation

This new options lets the escalation plugin use the pristine (unmapped) URL 
when retrying the request.

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

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

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

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

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

This closes #418


commit f6ada99b4379b78f1c0ccda94f085e3f7eb9e47b
Author: Leif Hedstrom 
Date:   2015-12-17T00:47:55Z

TS-4081 Adds --pristine to use pristine URL on escalation




> Allow escalate plugin to use the pristine URL when retrying
> ---
>
> Key: TS-4081
> URL: https://issues.apache.org/jira/browse/TS-4081
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.2.0
>
>
> We have a use case where the remap rules must modify the path for the primary 
> origin, but when escalating (using escalate.so) it must use the original 
> (pristine) URL. I have a patch which adds a --pristine option to the plugin, 
> telling it to base the escalated request on the pristine URL and not the 
> remapped URL.



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

[jira] [Commented] (TS-3922) Add independent WebSocket timeouts

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-3922:
--

Well I did this but never committed it upstream, landing today.

> Add independent WebSocket timeouts
> --
>
> Key: TS-3922
> URL: https://issues.apache.org/jira/browse/TS-3922
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 6.2.0
>
>
> Right now WebSockets fall under the active/inactive transaction timeouts. 
> Obviously the inactivate timeout isn't a problem but the active timeout is. 
> We need at minimum a new timeout for active WS connections, I'll likely add a 
> new timeout for inactive state too.



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

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF subversion and git services (JIRA)]

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

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

Commit 7cd050790b4cc6a85becebef7438e01f267f0bd3 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7cd0507 ]

TS-3072: fix newer compiler warnings.


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072-config.diff, ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



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

[jira] [Updated] (TS-4125) Wrong non-active conditions check

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4125:
---
Summary: Wrong non-active conditions check  (was: wrong non-active 
conditions check)

> Wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Closed] (TS-3930) Activity timeout doesn't close the connection

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3930.
--
Resolution: Fixed

> Activity timeout doesn't close the connection
> -
>
> Key: TS-3930
> URL: https://issues.apache.org/jira/browse/TS-3930
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.3.2, 6.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>




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

[jira] [Updated] (TS-3930) Activity timeout doesn't close the connection

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3930:
---
Fix Version/s: (was: 6.2.0)

> Activity timeout doesn't close the connection
> -
>
> Key: TS-3930
> URL: https://issues.apache.org/jira/browse/TS-3930
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.3.2, 6.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>




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

[jira] [Updated] (TS-4125) wrong non-active conditions check

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4125:
---
Affects Version/s: 6.0.0

> wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Updated] (TS-4125) wrong non-active conditions check

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4125:
---
Fix Version/s: 6.1.0

> wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Commented] (TS-4024) Wire tracing enhancements

[ASF subversion and git services (JIRA)]

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

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

Commit 3a8ee6ba7a42ca125d297ac8edeeba88df8636ad in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3a8ee6b ]

TS-4024: clang-format fix.


> Wire tracing enhancements
> -
>
> Key: TS-4024
> URL: https://issues.apache.org/jira/browse/TS-4024
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.2.0
>
>
> Some enhancements from Yahoo! to make wire tracing dynamically enable-able 
> and to enhance log messages.



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

[jira] [Commented] (TS-4125) Wrong non-active conditions check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4125:


Github user asfgit closed the pull request at:

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


> Wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Commented] (TS-4125) Wrong non-active conditions check

[ASF subversion and git services (JIRA)]

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

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

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

TS-4125: wrong non-active conditions check

This closes #416


> Wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Commented] (TS-4125) Wrong non-active conditions check

[ASF subversion and git services (JIRA)]

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

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

Commit 41964ab7662741d71de46286b7db8fb9a557a60f in trafficserver's branch 
refs/heads/6.1.x from Oknet
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=41964ab ]

TS-4125: wrong non-active conditions check

This closes #416

(cherry picked from commit c26952d95104067d45704d6c81eb3bc038fd2282)


> Wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Assigned] (TS-4125) Wrong non-active conditions check

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4125:
--

Assignee: Bryan Call

> Wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Resolved] (TS-4125) Wrong non-active conditions check

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4125.

Resolution: Fixed

> Wrong non-active conditions check
> -
>
> Key: TS-4125
> URL: https://issues.apache.org/jira/browse/TS-4125
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.0.0
>Reporter: Oknet Xu
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>
> In the NetHandler::manage_active_queue() function:
> we should close inactivity timeout vc that means 
> "vc->next_activity_timeout_at <= now".
> but "vc->next_activity_timeout_at > now" here.
> It's call _close_vc() for an activity vc and close vc early.
> {code}
>   for (; vc != NULL; vc = vc_next) {
> if ((vc->next_inactivity_timeout_at > now) || 
> (vc->next_activity_timeout_at > now)) {
>   _close_vc(vc, now, handle_event, closed, total_idle_time, 
> total_idle_count);
> }
> if (max_connections_active_per_thread_in > active_queue_size) {
>   return true;
> }
>   }
> {code}



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

[jira] [Commented] (TS-3841) LogAccess.cc assert failed when enabling custom log and stats_over_http plugin

[ASF subversion and git services (JIRA)]

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

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

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

TS-3841: LogAccess.cc assert failed when enabling custom log and 
stats_over_http plugin

(cherry picked from commit 9399a76410de027092b20e0a287f315fca20257d)


> LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
> --
>
> Key: TS-3841
> URL: https://issues.apache.org/jira/browse/TS-3841
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: taoyunxing
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>
> when I enable both the custom log and stats_over_http plugin, I encounter the 
> following problem:
> {code}
> FATAL: LogAccess.cc:816: failed assert `actual_len < padded_len`
> Program received signal SIGABRT, Aborted.
> (gdb) bt
> #0  0x003d150328a5 in raise () from /lib64/libc.so.6
> #1  0x003d15034085 in abort () from /lib64/libc.so.6
> #2  0x77dd8751 in ink_die_die_die () at ink_error.cc:43
> #3  0x77dd8808 in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (fmt=0x77dea738 "%s:%d: failed assert `%s`", 
> ap=0x75e1f430) at ink_error.cc:65
> #4  0x77dd88cd in ink_fatal (message_format=0x77dea738 "%s:%d: 
> failed assert `%s`") at ink_error.cc:73
> #5  0x77dd6272 in _ink_assert (expression=0x7e653b "actual_len < 
> padded_len", file=0x7e64c7 "LogAccess.cc", line=816) at ink_assert.cc:37
> #6  0x0066a2e2 in LogAccess::marshal_mem (dest=0x7fffec004358 "", 
> source=0x7e6539 "-", actual_len=1, padded_len=0) at LogAccess.cc:816
> #7  0x0066d455 in LogAccessHttp::marshal_client_req_unmapped_url_host 
> (this=0x75e1f7d0, buf=0x7fffec004358 "") at LogAccessHttp.cc:472
> #8  0x0067b441 in LogField::marshal (this=0x1110e80, 
> lad=0x75e1f7d0, buf=0x7fffec004358 "") at LogField.cc:276
> #9  0x0067bf5b in LogFieldList::marshal (this=0x110d5b0, 
> lad=0x75e1f7d0, buf=0x7fffec004318 "") at LogField.cc:574
> #10 0x0068b408 in LogObject::log (this=0x110d4e0, lad=0x75e1f7d0, 
> text_entry=0x0) at LogObject.cc:623
> #11 0x0068da22 in LogObjectManager::log (this=0x1116da8, 
> lad=0x75e1f7d0) at LogObject.cc:1331
> #12 0x00666d0e in Log::access (lad=0x75e1f7d0) at Log.cc:927
> #13 0x005f630d in HttpSM::kill_this (this=0x70ef1aa0) at 
> HttpSM.cc:6571
> #14 0x005e7184 in HttpSM::main_handler (this=0x70ef1aa0, 
> event=2301, data=0x70ef2ef8) at HttpSM.cc:2567
> #15 0x00506166 in Continuation::handleEvent (this=0x70ef1aa0, 
> event=2301, data=0x70ef2ef8) at ../iocore/eventsystem/I_Continuation.h:145
> #16 0x00635ad9 in HttpTunnel::main_handler (this=0x70ef2ef8, 
> event=103, data=0x718b2110) at HttpTunnel.cc:1585
> #17 0x00506166 in Continuation::handleEvent (this=0x70ef2ef8, 
> event=103, data=0x718b2110) at ../iocore/eventsystem/I_Continuation.h:145
> #18 0x00778bdb in write_signal_and_update (event=103, 
> vc=0x718b1f80) at UnixNetVConnection.cc:170
> #19 0x00778df3 in write_signal_done (event=103, nh=0x7622a780, 
> vc=0x718b1f80) at UnixNetVConnection.cc:212
> #20 0x00779f92 in write_to_net_io (nh=0x7622a780, 
> vc=0x718b1f80, thread=0x76227010) at UnixNetVConnection.cc:530
> #21 0x007796e9 in write_to_net (nh=0x7622a780, vc=0x718b1f80, 
> thread=0x76227010) at UnixNetVConnection.cc:384
> #22 0x0077245a in NetHandler::mainNetEvent (this=0x7622a780, 
> event=5, e=0x75a1eb40) at UnixNet.cc:562
> #23 0x00506166 in Continuation::handleEvent (this=0x7622a780, 
> event=5, data=0x75a1eb40) at ../iocore/eventsystem/I_Continuation.h:145
> #24 0x0079aa26 in EThread::process_event (this=0x76227010, 
> e=0x75a1eb40, calling_code=5) at UnixEThread.cc:128
> #25 0x0079b047 in EThread::execute (this=0x76227010) at 
> UnixEThread.cc:252
> #26 0x00799f2c in spawn_thread_internal (a=0x1106a40) at Thread.cc:85
> #27 0x003d15407851 in start_thread () from /lib64/libpthread.so.0
> #28 0x003d150e767d in clone () from /lib64/libc.so.6
> (gdb)
> {code}



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

[jira] [Updated] (TS-3841) LogAccess.cc assert failed when enabling custom log and stats_over_http plugin

[Bryan Call (JIRA)]

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

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

> LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
> --
>
> Key: TS-3841
> URL: https://issues.apache.org/jira/browse/TS-3841
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 5.3.0, 6.0.0
>Reporter: taoyunxing
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>
> when I enable both the custom log and stats_over_http plugin, I encounter the 
> following problem:
> {code}
> FATAL: LogAccess.cc:816: failed assert `actual_len < padded_len`
> Program received signal SIGABRT, Aborted.
> (gdb) bt
> #0  0x003d150328a5 in raise () from /lib64/libc.so.6
> #1  0x003d15034085 in abort () from /lib64/libc.so.6
> #2  0x77dd8751 in ink_die_die_die () at ink_error.cc:43
> #3  0x77dd8808 in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (fmt=0x77dea738 "%s:%d: failed assert `%s`", 
> ap=0x75e1f430) at ink_error.cc:65
> #4  0x77dd88cd in ink_fatal (message_format=0x77dea738 "%s:%d: 
> failed assert `%s`") at ink_error.cc:73
> #5  0x77dd6272 in _ink_assert (expression=0x7e653b "actual_len < 
> padded_len", file=0x7e64c7 "LogAccess.cc", line=816) at ink_assert.cc:37
> #6  0x0066a2e2 in LogAccess::marshal_mem (dest=0x7fffec004358 "", 
> source=0x7e6539 "-", actual_len=1, padded_len=0) at LogAccess.cc:816
> #7  0x0066d455 in LogAccessHttp::marshal_client_req_unmapped_url_host 
> (this=0x75e1f7d0, buf=0x7fffec004358 "") at LogAccessHttp.cc:472
> #8  0x0067b441 in LogField::marshal (this=0x1110e80, 
> lad=0x75e1f7d0, buf=0x7fffec004358 "") at LogField.cc:276
> #9  0x0067bf5b in LogFieldList::marshal (this=0x110d5b0, 
> lad=0x75e1f7d0, buf=0x7fffec004318 "") at LogField.cc:574
> #10 0x0068b408 in LogObject::log (this=0x110d4e0, lad=0x75e1f7d0, 
> text_entry=0x0) at LogObject.cc:623
> #11 0x0068da22 in LogObjectManager::log (this=0x1116da8, 
> lad=0x75e1f7d0) at LogObject.cc:1331
> #12 0x00666d0e in Log::access (lad=0x75e1f7d0) at Log.cc:927
> #13 0x005f630d in HttpSM::kill_this (this=0x70ef1aa0) at 
> HttpSM.cc:6571
> #14 0x005e7184 in HttpSM::main_handler (this=0x70ef1aa0, 
> event=2301, data=0x70ef2ef8) at HttpSM.cc:2567
> #15 0x00506166 in Continuation::handleEvent (this=0x70ef1aa0, 
> event=2301, data=0x70ef2ef8) at ../iocore/eventsystem/I_Continuation.h:145
> #16 0x00635ad9 in HttpTunnel::main_handler (this=0x70ef2ef8, 
> event=103, data=0x718b2110) at HttpTunnel.cc:1585
> #17 0x00506166 in Continuation::handleEvent (this=0x70ef2ef8, 
> event=103, data=0x718b2110) at ../iocore/eventsystem/I_Continuation.h:145
> #18 0x00778bdb in write_signal_and_update (event=103, 
> vc=0x718b1f80) at UnixNetVConnection.cc:170
> #19 0x00778df3 in write_signal_done (event=103, nh=0x7622a780, 
> vc=0x718b1f80) at UnixNetVConnection.cc:212
> #20 0x00779f92 in write_to_net_io (nh=0x7622a780, 
> vc=0x718b1f80, thread=0x76227010) at UnixNetVConnection.cc:530
> #21 0x007796e9 in write_to_net (nh=0x7622a780, vc=0x718b1f80, 
> thread=0x76227010) at UnixNetVConnection.cc:384
> #22 0x0077245a in NetHandler::mainNetEvent (this=0x7622a780, 
> event=5, e=0x75a1eb40) at UnixNet.cc:562
> #23 0x00506166 in Continuation::handleEvent (this=0x7622a780, 
> event=5, data=0x75a1eb40) at ../iocore/eventsystem/I_Continuation.h:145
> #24 0x0079aa26 in EThread::process_event (this=0x76227010, 
> e=0x75a1eb40, calling_code=5) at UnixEThread.cc:128
> #25 0x0079b047 in EThread::execute (this=0x76227010) at 
> UnixEThread.cc:252
> #26 0x00799f2c in spawn_thread_internal (a=0x1106a40) at Thread.cc:85
> #27 0x003d15407851 in start_thread () from /lib64/libpthread.so.0
> #28 0x003d150e767d in clone () from /lib64/libc.so.6
> (gdb)
> {code}



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

[jira] [Updated] (TS-3841) LogAccess.cc assert failed when enabling custom log and stats_over_http plugin

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3841:
---
Affects Version/s: 6.0.0

> LogAccess.cc assert failed when enabling custom log and stats_over_http plugin
> --
>
> Key: TS-3841
> URL: https://issues.apache.org/jira/browse/TS-3841
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 5.3.0, 6.0.0
>Reporter: taoyunxing
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>
> when I enable both the custom log and stats_over_http plugin, I encounter the 
> following problem:
> {code}
> FATAL: LogAccess.cc:816: failed assert `actual_len < padded_len`
> Program received signal SIGABRT, Aborted.
> (gdb) bt
> #0  0x003d150328a5 in raise () from /lib64/libc.so.6
> #1  0x003d15034085 in abort () from /lib64/libc.so.6
> #2  0x77dd8751 in ink_die_die_die () at ink_error.cc:43
> #3  0x77dd8808 in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (fmt=0x77dea738 "%s:%d: failed assert `%s`", 
> ap=0x75e1f430) at ink_error.cc:65
> #4  0x77dd88cd in ink_fatal (message_format=0x77dea738 "%s:%d: 
> failed assert `%s`") at ink_error.cc:73
> #5  0x77dd6272 in _ink_assert (expression=0x7e653b "actual_len < 
> padded_len", file=0x7e64c7 "LogAccess.cc", line=816) at ink_assert.cc:37
> #6  0x0066a2e2 in LogAccess::marshal_mem (dest=0x7fffec004358 "", 
> source=0x7e6539 "-", actual_len=1, padded_len=0) at LogAccess.cc:816
> #7  0x0066d455 in LogAccessHttp::marshal_client_req_unmapped_url_host 
> (this=0x75e1f7d0, buf=0x7fffec004358 "") at LogAccessHttp.cc:472
> #8  0x0067b441 in LogField::marshal (this=0x1110e80, 
> lad=0x75e1f7d0, buf=0x7fffec004358 "") at LogField.cc:276
> #9  0x0067bf5b in LogFieldList::marshal (this=0x110d5b0, 
> lad=0x75e1f7d0, buf=0x7fffec004318 "") at LogField.cc:574
> #10 0x0068b408 in LogObject::log (this=0x110d4e0, lad=0x75e1f7d0, 
> text_entry=0x0) at LogObject.cc:623
> #11 0x0068da22 in LogObjectManager::log (this=0x1116da8, 
> lad=0x75e1f7d0) at LogObject.cc:1331
> #12 0x00666d0e in Log::access (lad=0x75e1f7d0) at Log.cc:927
> #13 0x005f630d in HttpSM::kill_this (this=0x70ef1aa0) at 
> HttpSM.cc:6571
> #14 0x005e7184 in HttpSM::main_handler (this=0x70ef1aa0, 
> event=2301, data=0x70ef2ef8) at HttpSM.cc:2567
> #15 0x00506166 in Continuation::handleEvent (this=0x70ef1aa0, 
> event=2301, data=0x70ef2ef8) at ../iocore/eventsystem/I_Continuation.h:145
> #16 0x00635ad9 in HttpTunnel::main_handler (this=0x70ef2ef8, 
> event=103, data=0x718b2110) at HttpTunnel.cc:1585
> #17 0x00506166 in Continuation::handleEvent (this=0x70ef2ef8, 
> event=103, data=0x718b2110) at ../iocore/eventsystem/I_Continuation.h:145
> #18 0x00778bdb in write_signal_and_update (event=103, 
> vc=0x718b1f80) at UnixNetVConnection.cc:170
> #19 0x00778df3 in write_signal_done (event=103, nh=0x7622a780, 
> vc=0x718b1f80) at UnixNetVConnection.cc:212
> #20 0x00779f92 in write_to_net_io (nh=0x7622a780, 
> vc=0x718b1f80, thread=0x76227010) at UnixNetVConnection.cc:530
> #21 0x007796e9 in write_to_net (nh=0x7622a780, vc=0x718b1f80, 
> thread=0x76227010) at UnixNetVConnection.cc:384
> #22 0x0077245a in NetHandler::mainNetEvent (this=0x7622a780, 
> event=5, e=0x75a1eb40) at UnixNet.cc:562
> #23 0x00506166 in Continuation::handleEvent (this=0x7622a780, 
> event=5, data=0x75a1eb40) at ../iocore/eventsystem/I_Continuation.h:145
> #24 0x0079aa26 in EThread::process_event (this=0x76227010, 
> e=0x75a1eb40, calling_code=5) at UnixEThread.cc:128
> #25 0x0079b047 in EThread::execute (this=0x76227010) at 
> UnixEThread.cc:252
> #26 0x00799f2c in spawn_thread_internal (a=0x1106a40) at Thread.cc:85
> #27 0x003d15407851 in start_thread () from /lib64/libpthread.so.0
> #28 0x003d150e767d in clone () from /lib64/libc.so.6
> (gdb)
> {code}



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

[jira] [Commented] (TS-4116) DNS failure prohibits use of client target address

[Uri Shachar (JIRA)]

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

Uri Shachar commented on TS-4116:
-

Ok - I wasn't aware of TS-2954 (been a while since I had transparent 
deployments :-) )
I'll take a look

> DNS failure prohibits use of client target address
> --
>
> Key: TS-4116
> URL: https://issues.apache.org/jira/browse/TS-4116
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 5.3.2
>Reporter: Kalin Krastanov
> Fix For: 6.2.0
>
>
> When ATS is set up to use client target address in transparent mode and there 
> is DNS error (i.e. the OS name is resolvable only on the client machine) 502 
> error is returned instead of using the client target address.



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