[jira] [Commented] (TS-1007) SSN Close called before TXN Close
[ https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198116#comment-14198116 ] Nick Kew commented on TS-1007: -- Bah, can't log in to Jira. As usual. It is a complex workaround. Keep a txn count on the ssn, and if txn count 0 on ssn_close event, just mark it as closing and actually run cleanups it on the last txn_close. And don't use ssn mutex, because the ssn_close kills it! We now have the workaround, so I'd forgotten about this bug. So I guess it's not actually critical here. -- Nick Kew SSN Close called before TXN Close - Key: TS-1007 URL: https://issues.apache.org/jira/browse/TS-1007 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Nick Kew Assignee: Sudheer Vinukonda Priority: Critical Fix For: 5.3.0 Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the SSN_CLOSE_HOOK is called first of the two. This messes up normal cleanups! Details: Register a SSN_START event globally In the SSN START, add a TXN_START and a SSN_CLOSE In the TXN START, add a TXN_CLOSE Stepping through, I see the order of events actually called, for the simple case of a one-off HTTP request with no keepalive: SSN_START TXN_START SSN_END TXN_END Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the TXN! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-1712) Double Free Issue with Basic Auth Type Plugin
[
https://issues.apache.org/jira/browse/TS-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1712.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)
Double Free Issue with Basic Auth Type Plugin
-
Key: TS-1712
URL: https://issues.apache.org/jira/browse/TS-1712
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Valerie Thompson
Labels: Crash
I am creating a new plugin based off of basic-auth.c example from 3.0.5
version of ATS. When I load the plugin and start running traffic through it I
am getting memory issues and eventually crashes.
I plan on having a username and password for my plugin, and as I add more
features, the more unstable everything becomes. Today I stripped everything
down to the bare minimum and ran it as and here is an example of memory
issues, below. Let me know if you need further information.
uname info for the type of box I'm running on:
2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 16:11:42 CDT 2012 x86_64 x86_64
x86_64 GNU/Linux
{quote}
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x030c4ab0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3197275916]
/lib64/libc.so.6[0x3197278443]
/usr/lib64/trafficserver/plugins/ena-auth.so(+0x16a0)[0x2b051fc026a0]
/usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52d3e5]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x35a)[0x5222fa]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xac3)[0x537753]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
/usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
/usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x280)[0x52e760]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
/usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x202)[0x510d22]
/usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x4be)[0x65a41e]
/usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x170)[0x638910]
/usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x510674]
/usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0x151)[0x521ab1]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6f3)[0x537383]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
/usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7fd)[0x53748d]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
/usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
/usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
/usr/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x5ab)[0x52c06b]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
/usr/bin/traffic_server[0x68314b]
/usr/bin/traffic_server[0x685c71]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67e782]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6aaff4]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6ab983]
/usr/bin/traffic_server(main+0x1128)[0x4c0878]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x319721ecdd]
/usr/bin/traffic_server[0x47e149]
=== Memory map:
0040-00759000 r-xp fd:01 668319
[jira] [Closed] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1757.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
Will reopen when/if this happens again and we can characterize the issue and
fix the root cause.
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: Yunkai Zhang
Labels: A, crash, review
Attachments: 0001-TS-1757-workaround-to-fix-core-at-escapify_url.patch
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1767) Cache Lookup Regex using incorrect urls
[ https://issues.apache.org/jira/browse/TS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1767: --- Assignee: Alan M. Carroll Cache Lookup Regex using incorrect urls --- Key: TS-1767 URL: https://issues.apache.org/jira/browse/TS-1767 Project: Traffic Server Issue Type: Bug Components: Web UI Reporter: Scott Harris Assignee: Alan M. Carroll Fix For: 6.0.0 When using the cache regex lookup returned urls contain origin server not of incoming mapping to ats. Ie using map http://incoming http://10.1.1.1:8080 returned regex urls are : http://10.1.1.1:8080/blah instead of http://incoming/blah Selecting any of these results in Cache Lookup Failed, or missing in cluster Doing url lookup with incoming url returns valid result. Using version 3.2.4 running as a reverse proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1767) Cache Lookup Regex using incorrect urls
[ https://issues.apache.org/jira/browse/TS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1767: --- Fix Version/s: (was: sometime) 6.0.0 Cache Lookup Regex using incorrect urls --- Key: TS-1767 URL: https://issues.apache.org/jira/browse/TS-1767 Project: Traffic Server Issue Type: Bug Components: Web UI Reporter: Scott Harris Fix For: 6.0.0 When using the cache regex lookup returned urls contain origin server not of incoming mapping to ats. Ie using map http://incoming http://10.1.1.1:8080 returned regex urls are : http://10.1.1.1:8080/blah instead of http://incoming/blah Selecting any of these results in Cache Lookup Failed, or missing in cluster Doing url lookup with incoming url returns valid result. Using version 3.2.4 running as a reverse proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
[ https://issues.apache.org/jira/browse/TS-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1773: --- Assignee: Meera Mosale Nataraja Consistently use ink_atoi() (or one of the equivalent functions we provide) --- Key: TS-1773 URL: https://issues.apache.org/jira/browse/TS-1773 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Meera Mosale Nataraja Fix For: 5.3.0 Most of the code uses ink_atoi(), we should make sure we do so consistently. In addition, perhaps we want to expose our internal version to plugin APIs, since it does have additional features compared to atoi() / strtol(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
[ https://issues.apache.org/jira/browse/TS-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1773: --- Fix Version/s: (was: 5.2.0) 5.3.0 Consistently use ink_atoi() (or one of the equivalent functions we provide) --- Key: TS-1773 URL: https://issues.apache.org/jira/browse/TS-1773 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Fix For: 5.3.0 Most of the code uses ink_atoi(), we should make sure we do so consistently. In addition, perhaps we want to expose our internal version to plugin APIs, since it does have additional features compared to atoi() / strtol(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
[ https://issues.apache.org/jira/browse/TS-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1774: --- Fix Version/s: (was: 5.2.0) 6.0.0 Make ink_hrtime_get() in Thread.cc member of the Thread class - Key: TS-1774 URL: https://issues.apache.org/jira/browse/TS-1774 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: James Peach Labels: newbie Fix For: 6.0.0 It's somewhat confusing that e..g ink_get_hrtime() is not a member of the Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
[ https://issues.apache.org/jira/browse/TS-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1774: --- Labels: newbie (was: ) Make ink_hrtime_get() in Thread.cc member of the Thread class - Key: TS-1774 URL: https://issues.apache.org/jira/browse/TS-1774 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: James Peach Labels: newbie Fix For: 6.0.0 It's somewhat confusing that e..g ink_get_hrtime() is not a member of the Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
[ https://issues.apache.org/jira/browse/TS-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1774: --- Assignee: (was: James Peach) Make ink_hrtime_get() in Thread.cc member of the Thread class - Key: TS-1774 URL: https://issues.apache.org/jira/browse/TS-1774 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Labels: newbie Fix For: 6.0.0 It's somewhat confusing that e..g ink_get_hrtime() is not a member of the Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1774) Make ink_hrtime_get() in Thread.cc member of the Thread class
[ https://issues.apache.org/jira/browse/TS-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198608#comment-14198608 ] Alan M. Carroll commented on TS-1774: - The problem here is a global function (ink_get_hrtime()) depends on data in a class instance. For that reason it should be a method on the class, not a global function. Probably Thread::get_hrtime(). Make ink_hrtime_get() in Thread.cc member of the Thread class - Key: TS-1774 URL: https://issues.apache.org/jira/browse/TS-1774 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Labels: newbie Fix For: 6.0.0 It's somewhat confusing that e..g ink_get_hrtime() is not a member of the Thread class, yet, relies on Thread::cur_time. Why is that ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1775) Cleanup of ink_hrtime.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1775:
---
Fix Version/s: (was: 5.2.0)
6.0.0
Cleanup of ink_hrtime.{cc,h}
Key: TS-1775
URL: https://issues.apache.org/jira/browse/TS-1775
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: James Peach
Labels: newbie
Fix For: 6.0.0
A few things comes to mind:
1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
and I can't imagine there's a reason to not have it on (it'd completely break
like everything, in fact it would fail to compile since gethrtime() doesn't
exist?).
2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
that implements our own TSC code. Modern Unix flavors implements this already
in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
implementation).
3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
gettimeofday() on linux.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-1775) Cleanup of ink_hrtime.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-1775:
--
Assignee: Susan Hinrichs (was: James Peach)
Cleanup of ink_hrtime.{cc,h}
Key: TS-1775
URL: https://issues.apache.org/jira/browse/TS-1775
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Labels: newbie
Fix For: 6.0.0
A few things comes to mind:
1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
and I can't imagine there's a reason to not have it on (it'd completely break
like everything, in fact it would fail to compile since gethrtime() doesn't
exist?).
2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
that implements our own TSC code. Modern Unix flavors implements this already
in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
implementation).
3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
gettimeofday() on linux.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1776) Range requests not working right
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-1776. --- I will be fixing this as part of the Partial Object Caching effort. Range requests not working right Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: Alan M. Carroll Priority: Blocker Fix For: 5.3.0 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1775) Cleanup of ink_hrtime.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1775:
---
Labels: newbie (was: )
Cleanup of ink_hrtime.{cc,h}
Key: TS-1775
URL: https://issues.apache.org/jira/browse/TS-1775
Project: Traffic Server
Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: James Peach
Labels: newbie
Fix For: 6.0.0
A few things comes to mind:
1) Why do we have a NEED_HRTIME define? It's always on as far as I can tell,
and I can't imagine there's a reason to not have it on (it'd completely break
like everything, in fact it would fail to compile since gethrtime() doesn't
exist?).
2) We should eliminate the USE_TIME_STAMP_COUNTER_HRTIME define, and the code
that implements our own TSC code. Modern Unix flavors implements this already
in various way (e.g. glibc's gettimeofday() wrapper has a TSC user space
implementation).
3) On FreeBSD, jpeach points out that CLOCK_REALTIME is probably not the
optimal way to use clock_gettime(). He suggest using CLOCK_REALTIME_FAST or
CLOCK_MONOTONIC_FAST which is similar to the optimizations done with TSC for
gettimeofday() on linux.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1795) check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198618#comment-14198618 ] Susan Hinrichs commented on TS-1795: Should integrate script for TS-1789 into the make test target. check that records.config stays in sync --- Key: TS-1795 URL: https://issues.apache.org/jira/browse/TS-1795 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach Assignee: David Carlin Fix For: 5.3.0 We should integrate the script from TS-1789 into the build and make sure that records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1795) check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1795: --- Fix Version/s: (was: 5.2.0) 5.3.0 check that records.config stays in sync --- Key: TS-1795 URL: https://issues.apache.org/jira/browse/TS-1795 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach Assignee: James Peach Fix For: 5.3.0 We should integrate the script from TS-1789 into the build and make sure that records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
[
https://issues.apache.org/jira/browse/TS-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1798.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
Will re-open when/if this becomes an issue again.
Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
---
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Labels: Crash
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1803) Crash report: HttpTunnel::deallocate_buffers - IOBufferBlock::free - reclamable_freelist_free - ink_atomic_increment
[
https://issues.apache.org/jira/browse/TS-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1803.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
Will open when/if this occurs again.
Crash report: HttpTunnel::deallocate_buffers - IOBufferBlock::free -
reclamable_freelist_free - ink_atomic_increment
---
Key: TS-1803
URL: https://issues.apache.org/jira/browse/TS-1803
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Zhao Yongming
Assignee: Yunkai Zhang
Labels: Crash
{code}
Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=9'.
Program terminated with signal 11, Segmentation fault.
#0 ink_atomic_incrementint, int (f=value optimized out,
item=0x2b1b2c028990) at ink_atomic.h:160
160 return __sync_fetch_and_add(mem, (Type)count);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.80.el6_3.7.x86_64
keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.1.x86_64
libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64
libcom_err-1.41.12-12.el6.x86_64 libgcc-4.4.6-4.el6.x86_64
libselinux-2.0.94-5.3.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64
openssl-1.0.0-27.el6_4.2.x86_64 pcre-7.8-6.el6.x86_64 tcl-8.5.7-6.el6.x86_64
ts-verycdn-stable.2.0.1535-1.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 ink_atomic_incrementint, int (f=value optimized out,
item=0x2b1b2c028990) at ink_atomic.h:160
#1 reclaimable_freelist_free (f=value optimized out, item=0x2b1b2c028990)
at ink_queue_ext.cc:614
#2 0x00481fd1 in free_void (this=0x2b1ad6f76060) at
../lib/ts/Allocator.h:68
#3 dealloc (this=0x2b1ad6f76060) at ../iocore/eventsystem/P_IOBuffer.h:325
#4 IOBufferData::free (this=0x2b1ad6f76060) at
../iocore/eventsystem/P_IOBuffer.h:338
#5 0x00481f06 in operator= (this=0x2b1b71c49640) at
../lib/ts/Ptr.h:399
#6 clear (this=0x2b1b71c49640) at ../iocore/eventsystem/P_IOBuffer.h:426
#7 dealloc (this=0x2b1b71c49640) at ../iocore/eventsystem/P_IOBuffer.h:464
#8 IOBufferBlock::free (this=0x2b1b71c49640) at
../iocore/eventsystem/P_IOBuffer.h:470
#9 0x00481eb2 in clear (this=0x2b1b71c48b00) at
../iocore/eventsystem/P_IOBuffer.h:435
#10 dealloc (this=0x2b1b71c48b00) at ../iocore/eventsystem/P_IOBuffer.h:464
#11 IOBufferBlock::free (this=0x2b1b71c48b00) at
../iocore/eventsystem/P_IOBuffer.h:470
#12 0x005636c6 in operator= (this=0x2b1b391f7680) at
../../lib/ts/Ptr.h:399
#13 free_MIOBuffer (this=0x2b1b391f7680) at
../../iocore/eventsystem/P_IOBuffer.h:776
#14 HttpTunnel::deallocate_buffers (this=0x2b1b391f7680) at HttpTunnel.cc:535
#15 0x0052ab23 in HttpSM::kill_this (this=0x2b1b391f5af0) at
HttpSM.cc:6319
#16 0x0052b058 in HttpSM::main_handler (this=0x2b1b391f5af0,
event=100, data=0x2b1b4c5edd88) at HttpSM.cc:2516
#17 0x0066ba3b in handleEvent (event=value optimized out,
vc=0x2b1b4c5edc80) at ../../iocore/eventsystem/I_Continuation.h:146
#18 read_signal_and_update (event=value optimized out, vc=0x2b1b4c5edc80)
at UnixNetVConnection.cc:138
#19 0x00670054 in read_from_net (nh=0x2b1ac32f0bc0,
vc=0x2b1b4c5edc80, thread=value optimized out) at UnixNetVConnection.cc:320
#20 0x00667172 in NetHandler::mainNetEvent (this=0x2b1ac32f0bc0,
event=value optimized out, e=value optimized out) at UnixNet.cc:378
#21 0x0068f754 in handleEvent (this=0x2b1ac32ed010, e=0x2b1ac3dfe9c0,
calling_code=5) at I_Continuation.h:146
#22 EThread::process_event (this=0x2b1ac32ed010, e=0x2b1ac3dfe9c0,
calling_code=5) at UnixEThread.cc:142
#23 0x00690133 in EThread::execute (this=0x2b1ac32ed010) at
UnixEThread.cc:266
#24 0x0068e6d2 in spawn_thread_internal (a=0x27f5c40) at Thread.cc:88
#25 0x2b1abecf5851 in start_thread () from /lib64/libpthread.so.0
#26 0x2b1ac138711d in clone () from /lib64/libc.so.6
(gdb) f 14
#14 HttpTunnel::deallocate_buffers (this=0x2b1b391f7680) at HttpTunnel.cc:535
535 free_MIOBuffer(producers[i].read_buffer);
(gdb) p producers[i].read_buffer
value has been optimized out
(gdb) p producers[i]
value has been optimized out
(gdb) f 13
#13 free_MIOBuffer (this=0x2b1b391f7680) at
../../iocore/eventsystem/P_IOBuffer.h:776
776 mio-_writer = NULL;
(gdb) p mio
$1 = (MIOBuffer *) 0x2b1b7394d860
(gdb) p *mio
$2 = {size_index = 4, water_mark = 0, _writer = {m_ptr = 0x0}, readers =
{{accessor = 0x0, mbuf = 0x0, block = {m_ptr = 0x0}, start_offset = 0,
size_limit = 9223372036854775807}, {accessor = 0x0,
mbuf = 0x0, block = {m_ptr = 0x0}, start_offset = 0, size_limit =
[jira] [Updated] (TS-1808) openssl dynlock support
[ https://issues.apache.org/jira/browse/TS-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1808: --- Fix Version/s: (was: 5.2.0) sometime openssl dynlock support --- Key: TS-1808 URL: https://issues.apache.org/jira/browse/TS-1808 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Fix For: sometime OpenSSL has a thing called dynlock, which it uses to allocate locks on the fly, see CRYPTO_set_dynlock_create_callback() and friends. Apparently this can improve performance. We should implement OpenSSL dynlocks and measure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1807: Assignee: (was: William Bardwell) shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Fix For: sometime In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1808) openssl dynlock support
[ https://issues.apache.org/jira/browse/TS-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1808: --- Assignee: (was: James Peach) openssl dynlock support --- Key: TS-1808 URL: https://issues.apache.org/jira/browse/TS-1808 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Fix For: sometime OpenSSL has a thing called dynlock, which it uses to allocate locks on the fly, see CRYPTO_set_dynlock_create_callback() and friends. Apparently this can improve performance. We should implement OpenSSL dynlocks and measure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1809) remove HTTP_CACHE build option
[ https://issues.apache.org/jira/browse/TS-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1809: --- Fix Version/s: (was: sometime) 6.0.0 remove HTTP_CACHE build option -- Key: TS-1809 URL: https://issues.apache.org/jira/browse/TS-1809 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Assignee: Alan M. Carroll Fix For: 6.0.0 The HTTP_CACHE build option is probably not useful anymore. It's almost certainly broken and clutters up a lot of code. Let's remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1809) remove HTTP_CACHE build option
[ https://issues.apache.org/jira/browse/TS-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1809: --- Assignee: Alan M. Carroll remove HTTP_CACHE build option -- Key: TS-1809 URL: https://issues.apache.org/jira/browse/TS-1809 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Assignee: Alan M. Carroll Fix For: 6.0.0 The HTTP_CACHE build option is probably not useful anymore. It's almost certainly broken and clutters up a lot of code. Let's remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1810) IPv6 for Cluster management
[
https://issues.apache.org/jira/browse/TS-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1810:
---
Assignee: (was: Alan M. Carroll)
IPv6 for Cluster management
---
Key: TS-1810
URL: https://issues.apache.org/jira/browse/TS-1810
Project: Traffic Server
Issue Type: Improvement
Components: Clustering
Reporter: Leif Hedstrom
Fix For: sometime
It seems the management APIs (at least) for clustering are not IPv6 aware.
E.g.
{code}
typedef int TSNodeHandle_t;
typedef void (*TSClusterRPCFunction) (TSNodeHandle_t *node,
TSClusterRPCMsg_t *msg, int msg_data_len);
typedef void (*TSClusterStatusFunction) (TSNodeHandle_t *node,
TSNodeStatus_t s);
* Get the struct in_addr associated with the TSNodeHandle_t. *
tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in);
* Get the TSNodeHandle_t for the local node. *
tsapi void TSGetMyNodeHandle(TSNodeHandle_t *h);
tsapi int TSSendClusterRPC(TSNodeHandle_t *nh, TSClusterRPCMsg_t *msg);
{code}
As far as I can tell, TSNodeHandle_t is also how we represent the IP of the
cluster node. And since it's an int, it can only represent IPv4 addresses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1816) active_timeout may lead TS crash
[ https://issues.apache.org/jira/browse/TS-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1816: --- Fix Version/s: (was: 5.2.0) 5.3.0 active_timeout may lead TS crash Key: TS-1816 URL: https://issues.apache.org/jira/browse/TS-1816 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Labels: Crash Fix For: 5.3.0 1: client request with 'If-Modified-Since' 2: ts has no copy in the cache and prepare for cache write 3: ts send server without the field 'If-Modified-Since' 4: server response hdr is back (200 0K) 5: suppose the request`s If-Modified-Since reponse`s Last-Modified, ts will send client 304 back(HttpSM::setup_internal_transfer) 6: ts will do the tunnel_handler_cache_fill to write the response to cache the is a problem in step 5 and step 6. In step 5, all the event`s associated by server_session is also handled by HttpSM::state_read_server_response_header rather than the tunnel, which may lead to serious problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-1816) active_timeout may lead TS crash
[ https://issues.apache.org/jira/browse/TS-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-1816: -- Assignee: Susan Hinrichs active_timeout may lead TS crash Key: TS-1816 URL: https://issues.apache.org/jira/browse/TS-1816 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Susan Hinrichs Labels: Crash Fix For: 5.3.0 1: client request with 'If-Modified-Since' 2: ts has no copy in the cache and prepare for cache write 3: ts send server without the field 'If-Modified-Since' 4: server response hdr is back (200 0K) 5: suppose the request`s If-Modified-Since reponse`s Last-Modified, ts will send client 304 back(HttpSM::setup_internal_transfer) 6: ts will do the tunnel_handler_cache_fill to write the response to cache the is a problem in step 5 and step 6. In step 5, all the event`s associated by server_session is also handled by HttpSM::state_read_server_response_header rather than the tunnel, which may lead to serious problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1795) check that records.config stays in sync
[ https://issues.apache.org/jira/browse/TS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1795: --- Assignee: David Carlin (was: James Peach) check that records.config stays in sync --- Key: TS-1795 URL: https://issues.apache.org/jira/browse/TS-1795 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: James Peach Assignee: David Carlin Fix For: 5.3.0 We should integrate the script from TS-1789 into the build and make sure that records.config never gets stale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1818) investigate making Linux native AIO a runtime option
[ https://issues.apache.org/jira/browse/TS-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1818. -- Resolution: Won't Fix Fix Version/s: (was: 5.2.0) Will open new bug to track what should be the default AIO on Linux. investigate making Linux native AIO a runtime option Key: TS-1818 URL: https://issues.apache.org/jira/browse/TS-1818 Project: Traffic Server Issue Type: Improvement Components: Cache, Portability Reporter: James Peach Assignee: weijin More people would be able to test and experiment with the Linux AIO support if it was a runtime option rather than a compilation option. Let's investigate whether this is feasible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3169) Evaluate which should be the default AIO implementation for Linux
Susan Hinrichs created TS-3169: -- Summary: Evaluate which should be the default AIO implementation for Linux Key: TS-3169 URL: https://issues.apache.org/jira/browse/TS-3169 Project: Traffic Server Issue Type: Improvement Reporter: Susan Hinrichs [~zwoop] reports that performance improvements have been made to the native Linux AIO use. May want to change the default for Linux. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-1818) investigate making Linux native AIO a runtime option
[ https://issues.apache.org/jira/browse/TS-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198636#comment-14198636 ] Susan Hinrichs edited comment on TS-1818 at 11/5/14 4:54 PM: - Will open new bug to track what should be the default AIO on Linux. TS-3169 was (Author: shinrich): Will open new bug to track what should be the default AIO on Linux. investigate making Linux native AIO a runtime option Key: TS-1818 URL: https://issues.apache.org/jira/browse/TS-1818 Project: Traffic Server Issue Type: Improvement Components: Cache, Portability Reporter: James Peach Assignee: weijin More people would be able to test and experiment with the Linux AIO support if it was a runtime option rather than a compilation option. Let's investigate whether this is feasible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[ https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1822: --- Assignee: Phil Sorber (was: James Peach) Do we still need proxy.config.system.mmap_max ? --- Key: TS-1822 URL: https://issues.apache.org/jira/browse/TS-1822 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: sometime A long time ago, we added proxy.config.system.mmap_max to let the traffic_server increase the max number of mmap segments that we want to use. We currently set this to 2MM. I'm wondering, do we really need this still ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[ https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198643#comment-14198643 ] Susan Hinrichs commented on TS-1822: Could be unneeded by huge pages and reclaimable free lists. Then could remove this option. Do we still need proxy.config.system.mmap_max ? --- Key: TS-1822 URL: https://issues.apache.org/jira/browse/TS-1822 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: sometime A long time ago, we added proxy.config.system.mmap_max to let the traffic_server increase the max number of mmap segments that we want to use. We currently set this to 2MM. I'm wondering, do we really need this still ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[ https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1822: --- Fix Version/s: (was: sometime) 6.0.0 Do we still need proxy.config.system.mmap_max ? --- Key: TS-1822 URL: https://issues.apache.org/jira/browse/TS-1822 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: 6.0.0 A long time ago, we added proxy.config.system.mmap_max to let the traffic_server increase the max number of mmap segments that we want to use. We currently set this to 2MM. I'm wondering, do we really need this still ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[
https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198644#comment-14198644
]
Bryan Call commented on TS-1822:
I am also not seeing many mmaps being used on our production boxes either:
{code}
$ sudo cat /proc/$(pidof traffic_server)/maps | wc -l
3820
{code}
Do we still need proxy.config.system.mmap_max ?
---
Key: TS-1822
URL: https://issues.apache.org/jira/browse/TS-1822
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Phil Sorber
Fix For: 6.0.0
A long time ago, we added proxy.config.system.mmap_max to let the
traffic_server increase the max number of mmap segments that we want to use.
We currently set this to 2MM.
I'm wondering, do we really need this still ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1835) Restore ink_resource.{cc,h} functionality
[
https://issues.apache.org/jira/browse/TS-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1835:
---
Fix Version/s: (was: 6.0.0)
5.2.0
Restore ink_resource.{cc,h} functionality
-
Key: TS-1835
URL: https://issues.apache.org/jira/browse/TS-1835
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.2.0
I think we should eliminate the ink_resource memory tracking code. We already
have support for this when linking in with tcmalloc or jemalloc, rolling our
own seems pointless with these tools being available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1840) make install requires a compiler
[
https://issues.apache.org/jira/browse/TS-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1840.
--
Resolution: Won't Fix
Fix Version/s: (was: 5.2.0)
Not deemed a big use case.
make install requires a compiler
Key: TS-1840
URL: https://issues.apache.org/jira/browse/TS-1840
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Are we missing something during the build?
{noformat}
make[2]: Entering directory `/home/igalic/src/asf/trafficserver/mgmt/api'
Making install in remote
make[3]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
make[4]: Entering directory
`/home/igalic/src/asf/trafficserver/mgmt/api/remote'
/bin/mkdir -p '/opt/ats-trunk/lib'
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libtsmgmt.la '/opt/ats-trunk/lib'
libtool: install: warning: relinking `libtsmgmt.la'
libtool: install: (cd /home/igalic/src/asf/trafficserver/mgmt/api/remote;
/bin/bash /home/igalic/src/asf/trafficserver/libtool --silent --tag CXX
--mode=relink clang++ -std=c++11 -g -O3 -fno-strict-aliasing -Werror
-Qunused-arguments -Wno-invalid-offsetof -version-info 6:3:3 -o libtsmgmt.la
-rpath /opt/ats-trunk/lib CfgContextImpl.lo CfgContextManager.lo
CfgContextUtils.lo CoreAPIShared.lo EventCallback.lo GenericParser.lo
INKMgmtAPI.lo CoreAPIRemote.lo EventRegistration.lo NetworkUtilsRemote.lo
../../../lib/ts/libtsutil.la )
/home/igalic/src/asf/trafficserver/libtool: line 8982: clang++: command not
found
libtool: install: error: relink `libtsmgmt.la' with the above command before
installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1841) Use libloader to share libraries between plugins
[ https://issues.apache.org/jira/browse/TS-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1841. -- Resolution: Won't Fix Fix Version/s: (was: Docs) Not seen as a critical use case at the moment. Use libloader to share libraries between plugins Key: TS-1841 URL: https://issues.apache.org/jira/browse/TS-1841 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Igor Galić Right now we have two plugins with inter-dependent libraries, those are esi and combo_handler. We should split those up and use libloader to load the share dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1845) Make proxy.config.cache.max_doc_size configurable via conf_remap plugin
[ https://issues.apache.org/jira/browse/TS-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1845: --- Fix Version/s: (was: sometime) 5.3.0 Make proxy.config.cache.max_doc_size configurable via conf_remap plugin --- Key: TS-1845 URL: https://issues.apache.org/jira/browse/TS-1845 Project: Traffic Server Issue Type: Improvement Components: Cache, Plugins Reporter: David Carlin Fix For: 5.3.0 It would be very helpful if proxy.config.cache.max_doc_size and possibly proxy.config.cache.ram_cache_cutoff were configurable via the conf_remap plugin. Of the two, proxy.config.cache.max_doc_size is more important. Thank You! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1849) traffic_logstats does not accept relative log file paths
[ https://issues.apache.org/jira/browse/TS-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1849: --- Assignee: (was: Leif Hedstrom) traffic_logstats does not accept relative log file paths Key: TS-1849 URL: https://issues.apache.org/jira/browse/TS-1849 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: James Peach Labels: newbie Fix For: 5.3.0 From TS-1834, traffic_logstats pukes if you give it a relative path to a log file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1849) traffic_logstats does not accept relative log file paths
[ https://issues.apache.org/jira/browse/TS-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1849: --- Labels: newbie (was: ) traffic_logstats does not accept relative log file paths Key: TS-1849 URL: https://issues.apache.org/jira/browse/TS-1849 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: James Peach Labels: newbie Fix For: 5.3.0 From TS-1834, traffic_logstats pukes if you give it a relative path to a log file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1849) traffic_logstats does not accept relative log file paths
[ https://issues.apache.org/jira/browse/TS-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1849: --- Fix Version/s: (was: 5.2.0) 5.3.0 traffic_logstats does not accept relative log file paths Key: TS-1849 URL: https://issues.apache.org/jira/browse/TS-1849 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: James Peach Labels: newbie Fix For: 5.3.0 From TS-1834, traffic_logstats pukes if you give it a relative path to a log file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1831) traffic_logstats should not always require log dir access
[
https://issues.apache.org/jira/browse/TS-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1831.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)
[~zwoop] tested and could not see the problem.
traffic_logstats should not always require log dir access
-
Key: TS-1831
URL: https://issues.apache.org/jira/browse/TS-1831
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: James Peach
When running make check, the traffic_logstats test fails if the host system
does not have a current Traffic Server installation:
{code}
FAIL: tests/test_logstats_json
==
unable to change to log directory
/home/vagrant/build/proxy/var/log/trafficserver [2 'No such file or
directory']
please set correct path in env variable TS_ROOT
{code}
It's unreasonable for traffic_logstats to absolutely require the logdir to be
present. We should investigate whether the chdir failure can be weakened to a
warning instead of a hard error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1845) Make proxy.config.cache.max_doc_size configurable via conf_remap plugin
[ https://issues.apache.org/jira/browse/TS-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1845: --- Fix Version/s: (was: 5.3.0) sometime Make proxy.config.cache.max_doc_size configurable via conf_remap plugin --- Key: TS-1845 URL: https://issues.apache.org/jira/browse/TS-1845 Project: Traffic Server Issue Type: Improvement Components: Cache, Plugins Reporter: David Carlin Fix For: sometime It would be very helpful if proxy.config.cache.max_doc_size and possibly proxy.config.cache.ram_cache_cutoff were configurable via the conf_remap plugin. Of the two, proxy.config.cache.max_doc_size is more important. Thank You! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1869) Multiple cache lines in storage.config are ignored.
[ https://issues.apache.org/jira/browse/TS-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1869. -- Resolution: Fixed Fix Version/s: (was: sometime) Fixed via the duplicate bug. Multiple cache lines in storage.config are ignored. --- Key: TS-1869 URL: https://issues.apache.org/jira/browse/TS-1869 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Labels: A Using on-filesystem cache entries, and adding more than one line simply has no effect, only the last one seems to be used. It works fine for raw devices though. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1871) No Error on Startup if auto_conf Port is Unavailable
[ https://issues.apache.org/jira/browse/TS-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1871: --- Fix Version/s: (was: 5.2.0) 5.3.0 No Error on Startup if auto_conf Port is Unavailable Key: TS-1871 URL: https://issues.apache.org/jira/browse/TS-1871 Project: Traffic Server Issue Type: Bug Components: Manager Reporter: Clinton Wolfe Labels: newbie Fix For: 5.3.0 If another process is already listening on the auto_conf port (8083 by default), traffic_manager silently fails to bind to it. This can break heartbeats, because heartbeats are sent to the process on 8083 (which will probably not give the expected response as http://127.0.0.1:8083/synthetic.txt). With heartbeats broken, traffic_cop constantly re-starts traffic_server - which was the obvious symptom, in my case. Observed on ts 3.2.4, stock config, centos 5.9 discussed in #traffic-server on freenode IRC, ortho_stice (clintoncwolfe) and amc, 2013-05-01 and 2013-05-02 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1875) unable to start cop
[
https://issues.apache.org/jira/browse/TS-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1875.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
Supposed build/install issues. Will reopen if/when occurs again.
unable to start cop
---
Key: TS-1875
URL: https://issues.apache.org/jira/browse/TS-1875
Project: Traffic Server
Issue Type: Bug
Components: Core, Manager
Reporter: Zhao Yongming
will testing git master on my Fedora box, the cop is unable to start anymore,
hence that server and manager not able to start too.
here is something that I can get, tried many times, it is reproducable.
{code}
set_tid_address(0x7f8b85a6dad0) = 27282
set_robust_list(0x7f8b85a6dae0, 24) = 0
rt_sigaction(SIGRTMIN, {0x3e2d406650, [], SA_RESTORER|SA_SIGINFO,
0x3e2d40f000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x3e2d4066d0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO,
0x3e2d40f000}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
statfs(/sys/fs/selinux, 0x7fff2d596040) = -1 ENOENT (No such file or
directory)
statfs(/selinux, 0x7fff2d596040) = -1 ENOENT (No such file or
directory)
brk(0) = 0x84c000
brk(0x86d000) = 0x86d000
open(/proc/filesystems, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f8b85a8e000
read(3, nodev\tsysfs\nnodev\trootfs\nnodev\tb..., 1024) = 333
read(3, , 1024) = 0
close(3)= 0
munmap(0x7f8b85a8e000, 4096)= 0
^Z
[1]+ 已停止 strace -fF traffic_cop
[root@fc18150196 trafficserver]# bg
[1]+ strace -fF traffic_cop
[root@fc18150196 trafficserver]# bg
[1]+ strace -fF traffic_cop
--- SIGTSTP {si_signo=SIGTSTP, si_code=SI_KERNEL} ---
--- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=27107, si_uid=0} ---
[root@fc18150196 trafficserver]# top
top - 11:19:16 up 8 days, 6:19, 2 users, load average: 0.60, 0.91, 0.87
Tasks: 200 total, 3 running, 197 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.4 us, 0.6 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.2 hi, 0.0 si, 0.0
st
KiB Mem: 8149936 total, 4771200 used, 3378736 free, 320052 buffers
KiB Swap: 8159228 total,0 used, 8159228 free, 2270460 cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
27282 root 20 0 57732 1852 1448 R 104.7 0.0 0:13.00 traffic_cop
2281 zym 20 0 3130m 1.1g 1.1g S 6.5 14.2 449:23.80 VirtualBox
1 root 20 0 48548 4688 2140 S 0.0 0.1 0:04.24 systemd
2 root 20 0 000 S 0.0 0.0 0:00.03 kthreadd
3 root 20 0 000 S 0.0 0.0 0:02.55 ksoftirqd/0
5 root 0 -20 000 S 0.0 0.0 0:00.00 kworker/0:0H
7 root 0 -20 000 S 0.0 0.0 0:00.00 kworker/u:0H
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1871) No Error on Startup if auto_conf Port is Unavailable
[ https://issues.apache.org/jira/browse/TS-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1871: --- Assignee: (was: James Peach) No Error on Startup if auto_conf Port is Unavailable Key: TS-1871 URL: https://issues.apache.org/jira/browse/TS-1871 Project: Traffic Server Issue Type: Bug Components: Manager Reporter: Clinton Wolfe Labels: newbie Fix For: 5.3.0 If another process is already listening on the auto_conf port (8083 by default), traffic_manager silently fails to bind to it. This can break heartbeats, because heartbeats are sent to the process on 8083 (which will probably not give the expected response as http://127.0.0.1:8083/synthetic.txt). With heartbeats broken, traffic_cop constantly re-starts traffic_server - which was the obvious symptom, in my case. Observed on ts 3.2.4, stock config, centos 5.9 discussed in #traffic-server on freenode IRC, ortho_stice (clintoncwolfe) and amc, 2013-05-01 and 2013-05-02 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1871) No Error on Startup if auto_conf Port is Unavailable
[ https://issues.apache.org/jira/browse/TS-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1871: --- Labels: newbie (was: ) No Error on Startup if auto_conf Port is Unavailable Key: TS-1871 URL: https://issues.apache.org/jira/browse/TS-1871 Project: Traffic Server Issue Type: Bug Components: Manager Reporter: Clinton Wolfe Labels: newbie Fix For: 5.3.0 If another process is already listening on the auto_conf port (8083 by default), traffic_manager silently fails to bind to it. This can break heartbeats, because heartbeats are sent to the process on 8083 (which will probably not give the expected response as http://127.0.0.1:8083/synthetic.txt). With heartbeats broken, traffic_cop constantly re-starts traffic_server - which was the obvious symptom, in my case. Observed on ts 3.2.4, stock config, centos 5.9 discussed in #traffic-server on freenode IRC, ortho_stice (clintoncwolfe) and amc, 2013-05-01 and 2013-05-02 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1876) remove proxy.config.hostdb.storage_size configuration
[ https://issues.apache.org/jira/browse/TS-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1876: --- Fix Version/s: (was: 5.2.0) remove proxy.config.hostdb.storage_size configuration - Key: TS-1876 URL: https://issues.apache.org/jira/browse/TS-1876 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: James Peach HostDB has proxy.config.hostdb.storage_size (on-disk storage size) and proxy.config.hostdb.size (number of entries). If the number of entries doesn't fit, then it pukes. But this is pretty silly; admins should not need to figure this out. If should be enough to specify the number of entries that you need and let it happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1876) remove proxy.config.hostdb.storage_size configuration
[ https://issues.apache.org/jira/browse/TS-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1876. -- Resolution: Won't Fix remove proxy.config.hostdb.storage_size configuration - Key: TS-1876 URL: https://issues.apache.org/jira/browse/TS-1876 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: James Peach HostDB has proxy.config.hostdb.storage_size (on-disk storage size) and proxy.config.hostdb.size (number of entries). If the number of entries doesn't fit, then it pukes. But this is pretty silly; admins should not need to figure this out. If should be enough to specify the number of entries that you need and let it happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1878) link libraries as needed on linux
[
https://issues.apache.org/jira/browse/TS-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1878:
---
Fix Version/s: (was: 5.2.0)
6.0.0
link libraries as needed on linux
-
Key: TS-1878
URL: https://issues.apache.org/jira/browse/TS-1878
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Labels: newbie
Fix For: 6.0.0
We should pass {{-Wl,-as-needed}} to the linker on Linux to get it to strip
unused libraries. The equivalent Darwin option is {{-Wl,-dead_strip_dylibs}}.
See also:
http://www.gentoo.org/proj/en/qa/asneeded.xml
http://sigquit.wordpress.com/2011/02/16/why-asneeded-doesnt-work-as-expected-for-your-libraries-on-your-autotools-project/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1878) link libraries as needed on linux
[
https://issues.apache.org/jira/browse/TS-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1878:
---
Assignee: (was: James Peach)
link libraries as needed on linux
-
Key: TS-1878
URL: https://issues.apache.org/jira/browse/TS-1878
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
Priority: Minor
Labels: newbie
Fix For: 6.0.0
We should pass {{-Wl,-as-needed}} to the linker on Linux to get it to strip
unused libraries. The equivalent Darwin option is {{-Wl,-dead_strip_dylibs}}.
See also:
http://www.gentoo.org/proj/en/qa/asneeded.xml
http://sigquit.wordpress.com/2011/02/16/why-asneeded-doesnt-work-as-expected-for-your-libraries-on-your-autotools-project/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1878) link libraries as needed on linux
[
https://issues.apache.org/jira/browse/TS-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1878:
---
Labels: newbie (was: )
link libraries as needed on linux
-
Key: TS-1878
URL: https://issues.apache.org/jira/browse/TS-1878
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
Priority: Minor
Labels: newbie
Fix For: 6.0.0
We should pass {{-Wl,-as-needed}} to the linker on Linux to get it to strip
unused libraries. The equivalent Darwin option is {{-Wl,-dead_strip_dylibs}}.
See also:
http://www.gentoo.org/proj/en/qa/asneeded.xml
http://sigquit.wordpress.com/2011/02/16/why-asneeded-doesnt-work-as-expected-for-your-libraries-on-your-autotools-project/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1883) SSL origin connections do not support connection timeouts
[
https://issues.apache.org/jira/browse/TS-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1883:
---
Fix Version/s: (was: 6.0.0)
5.3.0
SSL origin connections do not support connection timeouts
-
Key: TS-1883
URL: https://issues.apache.org/jira/browse/TS-1883
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: James Peach
Assignee: Susan Hinrichs
Fix For: 5.3.0
In {{proxy/http/HttpSM.cc}}, we can see that origin connections do not
support timeouts if the scheme is HTTPS:
{code}
void
HttpSM::do_http_server_open(bool raw)
{
...
if (t_state.scheme == URL_WKSIDX_HTTPS) {
DebugSM(http, calling sslNetProcessor.connect_re);
connect_action_handle = sslNetProcessor.connect_re(this,// state
machine
t_state.current.server-addr.sa,// addr + port
opt);
} else {
...
// Setup the timeouts
// Set the inactivity timeout to the connect timeout so that we
// we fail this server if it doesn't start sending the response
// header
MgmtInt connect_timeout;
if (t_state.method == HTTP_WKSIDX_POST || t_state.method ==
HTTP_WKSIDX_PUT) {
connect_timeout = t_state.txn_conf-post_connect_attempts_timeout;
} else if (t_state.current.server == t_state.parent_info) {
connect_timeout = t_state.http_config_param-parent_connect_timeout;
} else {
if (t_state.pCongestionEntry != NULL)
connect_timeout = t_state.pCongestionEntry-connect_timeout();
else
connect_timeout = t_state.txn_conf-connect_attempts_timeout;
}
DebugSM(http, calling netProcessor.connect_s);
connect_action_handle = netProcessor.connect_s(this, // state
machine
t_state.current.server-addr.sa,// addr + port
connect_timeout, opt);
...
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1908) ATS shouldn't accept connections to a down destination in transparent mode
[ https://issues.apache.org/jira/browse/TS-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1908: --- Assignee: (was: Alan M. Carroll) ATS shouldn't accept connections to a down destination in transparent mode -- Key: TS-1908 URL: https://issues.apache.org/jira/browse/TS-1908 Project: Traffic Server Issue Type: New Feature Components: Network, TProxy Reporter: Ebrahim Mohammadi Fix For: 5.2.0 ATS shouldn't accept connections whose destination host/port is down while working in transparent mode. Currently hosts in a network with a transparent ATS intercepting all to-port-80 TCP connection will see TCP port 80 of all IP addresses as open and accepting connections, while most of them are in fact closed. This is against transparency of the transparent web cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1906) crash at BaseStatPagesHandler::resp_add
[
https://issues.apache.org/jira/browse/TS-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1906.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
crash at BaseStatPagesHandler::resp_add
---
Key: TS-1906
URL: https://issues.apache.org/jira/browse/TS-1906
Project: Traffic Server
Issue Type: Bug
Components: Web UI
Reporter: Bin Chen
Labels: Crash
{code}
#0 0x003984b3ef48 in __memcpy_ssse3_back () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64
libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 0x003984b3ef48 in __memcpy_ssse3_back () from /lib64/libc.so.6
#1 0x004e59f0 in BaseStatPagesHandler::resp_add
(this=0x2ad6205cdf10, fmt=value optimized out) at StatPages.cc:181
code
#2 0x0057658c in HttpPagesHandler::handle_smlist
(this=0x2ad6205cdf10, event=value optimized out, data=value optimized out)
at HttpPages.cc:419
#3 0x006aa0b4 in handleEvent (this=0x2ad60931d010, e=0x2ad6402cf310,
calling_code=1) at I_Continuation.h:146
#4 EThread::process_event (this=0x2ad60931d010, e=0x2ad6402cf310,
calling_code=1) at UnixEThread.cc:142
#5 0x006aac1b in EThread::execute (this=0x2ad60931d010) at
UnixEThread.cc:193
#6 0x006a9052 in spawn_thread_internal (a=0x317b860) at Thread.cc:88
#7 0x003984e077f1 in start_thread () from /lib64/libpthread.so.0
#8 0x003984ae570d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x004e59f0 in BaseStatPagesHandler::resp_add
(this=0x2ad6205cdf10, fmt=value optimized out) at StatPages.cc:181
/usr/src/debug/trafficserver-3.2.0/proxy/StatPages.cc:181:4220:beg:0x4e59f0
(gdb) l
176 response = (char *)ats_realloc(response, size);
177 }
178 response_size = size;
179 }
180
181 memcpy(response[response_length], buf, length + 1);
182 response_length += length;
183 }
184
185 void
(gdb) p length
$1 = 38015
{code}
char buf[16384], but length = 38015
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1908) ATS shouldn't accept connections to a down destination in transparent mode
[ https://issues.apache.org/jira/browse/TS-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1908. -- Resolution: Won't Fix Fix Version/s: (was: 5.2.0) This would be very hard to defer the client side accept before verifying that the connection to the OS will work. At this point not seen as a sufficiently critical use case. ATS shouldn't accept connections to a down destination in transparent mode -- Key: TS-1908 URL: https://issues.apache.org/jira/browse/TS-1908 Project: Traffic Server Issue Type: New Feature Components: Network, TProxy Reporter: Ebrahim Mohammadi ATS shouldn't accept connections whose destination host/port is down while working in transparent mode. Currently hosts in a network with a transparent ATS intercepting all to-port-80 TCP connection will see TCP port 80 of all IP addresses as open and accepting connections, while most of them are in fact closed. This is against transparency of the transparent web cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1916) There are cases where hostdb does not reference a ttl of nameserver.
[ https://issues.apache.org/jira/browse/TS-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1916. -- Resolution: Cannot Reproduce Unclear from the description what exactly is happening. James says that the code appears to be doing the right thing. Will reopen if this is still being seen. There are cases where hostdb does not reference a ttl of nameserver. Key: TS-1916 URL: https://issues.apache.org/jira/browse/TS-1916 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: ishioka keiichi Fix For: sometime hostdb is set as follows: CONFIG proxy.config.hostdb.ttl_mode INT 0 CONFIG proxy.config.hostdb.timeout INT 1 If response of dns the next,ATS queries the DNS every 30 seconds. $ dig foo.bar.com. A ;; ANSWER SECTION: foo.bar.com. 30 IN A 10.10.10.1 If ttl is reduced as follow:, ATS will query the DNS every 10 seconds. $ dig foo.bar.com. A ;; ANSWER SECTION: foo.bar.com. 300 IN A 10.10.10.1 However, if it increased the value of ttl, ATS has continued to query DNS every 10 seconds. $ dig foo.bar.com. A ;; ANSWER SECTION: foo.bar.com. 300 IN A 10.10.10.1 However, is adapted then HUP the traffic_server... Why?? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198708#comment-14198708
]
Alan M. Carroll commented on TS-1917:
-
I worked with this quite a bit but wasn't able to fully eliminate the issue. I
think it's intractable at this point.
It seems that one of assert in HttpTransact::handle_content_length_header()
is unnecessary
---
Key: TS-1917
URL: https://issues.apache.org/jira/browse/TS-1917
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Alan M. Carroll
Labels: review
Fix For: 6.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`,
ap=0x2b34979073a0) at ink_error.cc:65
#4 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
OK) at HttpTransact.cc:7731
#8 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
By analyzing the code, it seems that this assertion is unnecessary:
When client sends a request to ATS, and the content hits in cache, but if the
cache is STALE, ATS will sent a request to Original-Server.
In this case, the t_sate.source will be updated to
SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
[jira] [Closed] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1917.
--
Resolution: Won't Fix
Alan tracked down and found that it could not be removed.
It seems that one of assert in HttpTransact::handle_content_length_header()
is unnecessary
---
Key: TS-1917
URL: https://issues.apache.org/jira/browse/TS-1917
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Alan M. Carroll
Labels: review
Fix For: 6.0.0
Attachments: ts-1917.wj.diff
ATS crashed by the following assert in debug mode:
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`,
ap=0x2b34979073a0) at ink_error.cc:65
#4 0x2b349592e3ca in ink_fatal (return_code=1,
message_format=0x2b349594a748 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 s-range_setup !=
RANGE_NOT_TRANSFORM_REQUESTED, file=0x70a613 HttpTransact.cc, line=6660)
at ink_assert.cc:37
#6 0x0059cb57 in HttpTransact::handle_content_length_header
(s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
HttpTransact.cc:6660
#7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
OK) at HttpTransact.cc:7731
#8 0x00594972 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b34b1207120) at HttpTransact.cc:4373
#9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
(s=0x2b34b1207120) at HttpTransact.cc:3818
#10 0x00590c08 in HttpTransact::handle_response_from_server
(s=0x2b34b1207120) at HttpTransact.cc:3495
#11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
HttpTransact.cc:3185
#12 0x00575f25 in HttpSM::call_transact_and_set_next_state
(this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
#13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
HttpSM.cc:1555
#14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
event=0, data=0x0) at HttpSM.cc:1487
#15 0x0056f79b in HttpSM::do_api_callout_internal
(this=0x2b34b12070b0) at HttpSM.cc:4702
#16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
HttpSM.cc:503
#17 0x00564b68 in HttpSM::state_read_server_response_header
(this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
#18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
#19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x006ba540 in read_signal_and_update (event=100,
vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
#21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
#22 0x006bcc7f in UnixNetVConnection::net_read_io
(this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
UnixNetVConnection.cc:818
#23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
event=5, e=0x2b349cf16b40) at UnixNet.cc:377
#24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
#25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
#26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
UnixEThread.cc:265
#27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
#28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
By analyzing the code, it seems that this assertion is unnecessary:
When client sends a request to ATS, and the content hits in cache, but if the
cache is STALE, ATS will sent a request to Original-Server.
In this case, the t_sate.source will be updated to
SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
HttpTransact::handle_cache_operation_on_forward_server_response()
= s-state_machine-do_range_setup_if_necessary(), the
[jira] [Created] (TS-3170) Remove autoconf.pac feature
Susan Hinrichs created TS-3170: -- Summary: Remove autoconf.pac feature Key: TS-3170 URL: https://issues.apache.org/jira/browse/TS-3170 Project: Traffic Server Issue Type: Improvement Reporter: Susan Hinrichs This is a legacy feature no longer needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3170) Remove autoconf.pac feature
[ https://issues.apache.org/jira/browse/TS-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3170: --- Fix Version/s: 6.0.0 Remove autoconf.pac feature --- Key: TS-3170 URL: https://issues.apache.org/jira/browse/TS-3170 Project: Traffic Server Issue Type: Improvement Reporter: Susan Hinrichs Fix For: 6.0.0 This is a legacy feature no longer needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1922) proxy.config.admin.autoconf.pac_filename is not used as expected
[
https://issues.apache.org/jira/browse/TS-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1922.
--
Resolution: Won't Fix
Fix Version/s: (was: sometime)
Removing the feature.
proxy.config.admin.autoconf.pac_filename is not used as expected
Key: TS-1922
URL: https://issues.apache.org/jira/browse/TS-1922
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Leif Hedstrom
It seems that we have a config
{code}
proxy.config.admin.autoconf.pac_filename
{code}
to specify the proxy.pac file name. However, the code is hardocoded to use
proxy.pac.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1933) Uninformative warnings from traffic_manager on startup
[
https://issues.apache.org/jira/browse/TS-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1933:
---
Assignee: (was: Leif Hedstrom)
Uninformative warnings from traffic_manager on startup
--
Key: TS-1933
URL: https://issues.apache.org/jira/browse/TS-1933
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Leif Hedstrom
Fix For: 5.2.0
During startup, traffic_manager always seems to produce these errors:
{code}
[Jun 1 14:59:46.577] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
Cleaning up and reissuing signal #2
[Jun 1 14:59:46.578] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
signal #2
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
{code}
They seem harmless, but annoying.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1935: --- Assignee: Bryan Call ERR_UNKNOWN/000 showing up 10.4% of the time in production logs --- Key: TS-1935 URL: https://issues.apache.org/jira/browse/TS-1935 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.2.0 Need to investigate in what conditions this happens. * Keep-alive or not * If any requests have happened on the connection * Is the client or the server closing the connection at the time * Verify no bytes have been sent from the client, looking at the code it looks like it Ideally if the client has not sent any bytes (has not attempted to make a request) then we shouldn't log the error message. If it is possible a state machine should not be created in this scenario. related bug: TS-1056 related checkin: 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 I also see this happening in on my forward proxy using Chrome: [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1935: --- Fix Version/s: (was: 5.2.0) 5.3.0 ERR_UNKNOWN/000 showing up 10.4% of the time in production logs --- Key: TS-1935 URL: https://issues.apache.org/jira/browse/TS-1935 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.3.0 Need to investigate in what conditions this happens. * Keep-alive or not * If any requests have happened on the connection * Is the client or the server closing the connection at the time * Verify no bytes have been sent from the client, looking at the code it looks like it Ideally if the client has not sent any bytes (has not attempted to make a request) then we shouldn't log the error message. If it is possible a state machine should not be created in this scenario. related bug: TS-1056 related checkin: 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 I also see this happening in on my forward proxy using Chrome: [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-1944) ink_assert in CacheVC::updateVector()
[
https://issues.apache.org/jira/browse/TS-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs reassigned TS-1944:
--
Assignee: Susan Hinrichs
ink_assert in CacheVC::updateVector()
-
Key: TS-1944
URL: https://issues.apache.org/jira/browse/TS-1944
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Yunkai Zhang
Assignee: Susan Hinrichs
Labels: crash
Fix For: 5.2.0
Compile TS in --enable-debug mode,
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b56379ad234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b56379ad301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b56379c9768 %s:%d: failed assert `%s`,
ap=0x2b563da166e0) at ink_error.cc:65
#4 0x2b56379ad3ca in ink_fatal (return_code=1,
message_format=0x2b56379c9768 %s:%d: failed assert `%s`)
at ink_error.cc:73
#5 0x2b56379ac2cc in _ink_assert (expression=0x74c2e4 !fragment ||
f.data_done, file=0x74c27a CacheWrite.cc,
line=124) at ink_assert.cc:37
#6 0x00693a92 in CacheVC::updateVector (this=0x2b5664ffeb40) at
CacheWrite.cc:124
#7 0x00699b21 in CacheVC::openWriteCloseHead (this=0x2b5664ffeb40,
event=0, e=0x0) at CacheWrite.cc:1187
#8 0x0069a169 in CacheVC::openWriteClose (this=0x2b5664ffeb40,
event=0, e=0x0) at CacheWrite.cc:1279
#9 0x00673b3b in CacheVC::die (this=0x2b5664ffeb40) at
P_CacheInternal.h:683
#10 0x00692f47 in CacheVC::calluser (this=0x2b5664ffeb40, event=103)
at P_CacheInternal.h:625
#11 0x0069a716 in CacheVC::openWriteMain (this=0x2b5664ffeb40) at
CacheWrite.cc:1349
#12 0x0069a5e9 in CacheVC::openWriteWriteDone (this=0x2b5664ffeb40,
event=3900, e=0x0) at CacheWrite.cc:1327
#13 0x004e0f52 in Continuation::handleEvent (this=0x2b5664ffeb40,
event=3900, data=0x0)
at ../iocore/eventsystem/I_Continuation.h:146
#14 0x006844c7 in CacheVC::handleWriteLock (this=0x2b5664ffeb40,
event=4, e=0x0) at P_CacheInternal.h:714
#15 0x0069c9e8 in CacheVC::do_write_lock_call (this=0x2b5664ffeb40)
at P_CacheInternal.h:729
#16 0x0069aafd in CacheVC::openWriteMain (this=0x2b5664ffeb40) at
CacheWrite.cc:1400
#17 0x004e0f52 in Continuation::handleEvent (this=0x2b5664ffeb40,
event=1, data=0x2b56500026a0)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006dbcfc in EThread::process_event (this=0x2b563c202010,
e=0x2b56500026a0, calling_code=1)
at UnixEThread.cc:141
#19 0x006dbf4c in EThread::execute (this=0x2b563c202010) at
UnixEThread.cc:192
#20 0x006daf08 in spawn_thread_internal (a=0x159d140) at Thread.cc:88
#21 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1944) ink_assert in CacheVC::updateVector()
[
https://issues.apache.org/jira/browse/TS-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1944:
---
Assignee: Alan M. Carroll (was: Susan Hinrichs)
ink_assert in CacheVC::updateVector()
-
Key: TS-1944
URL: https://issues.apache.org/jira/browse/TS-1944
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Yunkai Zhang
Assignee: Alan M. Carroll
Labels: crash
Fix For: 5.2.0
Compile TS in --enable-debug mode,
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b56379ad234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b56379ad301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b56379c9768 %s:%d: failed assert `%s`,
ap=0x2b563da166e0) at ink_error.cc:65
#4 0x2b56379ad3ca in ink_fatal (return_code=1,
message_format=0x2b56379c9768 %s:%d: failed assert `%s`)
at ink_error.cc:73
#5 0x2b56379ac2cc in _ink_assert (expression=0x74c2e4 !fragment ||
f.data_done, file=0x74c27a CacheWrite.cc,
line=124) at ink_assert.cc:37
#6 0x00693a92 in CacheVC::updateVector (this=0x2b5664ffeb40) at
CacheWrite.cc:124
#7 0x00699b21 in CacheVC::openWriteCloseHead (this=0x2b5664ffeb40,
event=0, e=0x0) at CacheWrite.cc:1187
#8 0x0069a169 in CacheVC::openWriteClose (this=0x2b5664ffeb40,
event=0, e=0x0) at CacheWrite.cc:1279
#9 0x00673b3b in CacheVC::die (this=0x2b5664ffeb40) at
P_CacheInternal.h:683
#10 0x00692f47 in CacheVC::calluser (this=0x2b5664ffeb40, event=103)
at P_CacheInternal.h:625
#11 0x0069a716 in CacheVC::openWriteMain (this=0x2b5664ffeb40) at
CacheWrite.cc:1349
#12 0x0069a5e9 in CacheVC::openWriteWriteDone (this=0x2b5664ffeb40,
event=3900, e=0x0) at CacheWrite.cc:1327
#13 0x004e0f52 in Continuation::handleEvent (this=0x2b5664ffeb40,
event=3900, data=0x0)
at ../iocore/eventsystem/I_Continuation.h:146
#14 0x006844c7 in CacheVC::handleWriteLock (this=0x2b5664ffeb40,
event=4, e=0x0) at P_CacheInternal.h:714
#15 0x0069c9e8 in CacheVC::do_write_lock_call (this=0x2b5664ffeb40)
at P_CacheInternal.h:729
#16 0x0069aafd in CacheVC::openWriteMain (this=0x2b5664ffeb40) at
CacheWrite.cc:1400
#17 0x004e0f52 in Continuation::handleEvent (this=0x2b5664ffeb40,
event=1, data=0x2b56500026a0)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006dbcfc in EThread::process_event (this=0x2b563c202010,
e=0x2b56500026a0, calling_code=1)
at UnixEThread.cc:141
#19 0x006dbf4c in EThread::execute (this=0x2b563c202010) at
UnixEThread.cc:192
#20 0x006daf08 in spawn_thread_internal (a=0x159d140) at Thread.cc:88
#21 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1939) proxy PAC configuration is confusing
[ https://issues.apache.org/jira/browse/TS-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1939. -- Resolution: Won't Fix Fix Version/s: (was: 5.2.0) proxy PAC configuration is confusing Key: TS-1939 URL: https://issues.apache.org/jira/browse/TS-1939 Project: Traffic Server Issue Type: Bug Components: Configuration, Documentation Reporter: James Peach The Forward Proxy documentation http://trafficserver.apache.org/docs/trunk/admin/forward-proxy/index.en.html, refers to the proxy.config.url_remap.default_to_server_pac setting but doesn't explain it well. The Explicit Proxy Caching documentation http://trafficserver.apache.org/docs/trunk/admin/explicit-proxy-caching/index.en.html does a better job, but doesn't really explain how the corresponding remap.config settings work and why you might use them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1944) ink_assert in CacheVC::updateVector()
[
https://issues.apache.org/jira/browse/TS-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198730#comment-14198730
]
Susan Hinrichs commented on TS-1944:
[~amc] says that he has fixed this. He will verify the code change.
ink_assert in CacheVC::updateVector()
-
Key: TS-1944
URL: https://issues.apache.org/jira/browse/TS-1944
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Yunkai Zhang
Assignee: Alan M. Carroll
Labels: crash
Fix For: 5.2.0
Compile TS in --enable-debug mode,
{code}
(gdb) bt
#0 0x003e86c32885 in raise () from /lib64/libc.so.6
#1 0x003e86c34065 in abort () from /lib64/libc.so.6
#2 0x2b56379ad234 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b56379ad301 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b56379c9768 %s:%d: failed assert `%s`,
ap=0x2b563da166e0) at ink_error.cc:65
#4 0x2b56379ad3ca in ink_fatal (return_code=1,
message_format=0x2b56379c9768 %s:%d: failed assert `%s`)
at ink_error.cc:73
#5 0x2b56379ac2cc in _ink_assert (expression=0x74c2e4 !fragment ||
f.data_done, file=0x74c27a CacheWrite.cc,
line=124) at ink_assert.cc:37
#6 0x00693a92 in CacheVC::updateVector (this=0x2b5664ffeb40) at
CacheWrite.cc:124
#7 0x00699b21 in CacheVC::openWriteCloseHead (this=0x2b5664ffeb40,
event=0, e=0x0) at CacheWrite.cc:1187
#8 0x0069a169 in CacheVC::openWriteClose (this=0x2b5664ffeb40,
event=0, e=0x0) at CacheWrite.cc:1279
#9 0x00673b3b in CacheVC::die (this=0x2b5664ffeb40) at
P_CacheInternal.h:683
#10 0x00692f47 in CacheVC::calluser (this=0x2b5664ffeb40, event=103)
at P_CacheInternal.h:625
#11 0x0069a716 in CacheVC::openWriteMain (this=0x2b5664ffeb40) at
CacheWrite.cc:1349
#12 0x0069a5e9 in CacheVC::openWriteWriteDone (this=0x2b5664ffeb40,
event=3900, e=0x0) at CacheWrite.cc:1327
#13 0x004e0f52 in Continuation::handleEvent (this=0x2b5664ffeb40,
event=3900, data=0x0)
at ../iocore/eventsystem/I_Continuation.h:146
#14 0x006844c7 in CacheVC::handleWriteLock (this=0x2b5664ffeb40,
event=4, e=0x0) at P_CacheInternal.h:714
#15 0x0069c9e8 in CacheVC::do_write_lock_call (this=0x2b5664ffeb40)
at P_CacheInternal.h:729
#16 0x0069aafd in CacheVC::openWriteMain (this=0x2b5664ffeb40) at
CacheWrite.cc:1400
#17 0x004e0f52 in Continuation::handleEvent (this=0x2b5664ffeb40,
event=1, data=0x2b56500026a0)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006dbcfc in EThread::process_event (this=0x2b563c202010,
e=0x2b56500026a0, calling_code=1)
at UnixEThread.cc:141
#19 0x006dbf4c in EThread::execute (this=0x2b563c202010) at
UnixEThread.cc:192
#20 0x006daf08 in spawn_thread_internal (a=0x159d140) at Thread.cc:88
#21 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x003e86ce5ccd in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198732#comment-14198732 ] Bryan Call commented on TS-1935: Leif would like to have this configurable, so he still look at these in the squid log. ERR_UNKNOWN/000 showing up 10.4% of the time in production logs --- Key: TS-1935 URL: https://issues.apache.org/jira/browse/TS-1935 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.3.0 Need to investigate in what conditions this happens. * Keep-alive or not * If any requests have happened on the connection * Is the client or the server closing the connection at the time * Verify no bytes have been sent from the client, looking at the code it looks like it Ideally if the client has not sent any bytes (has not attempted to make a request) then we shouldn't log the error message. If it is possible a state machine should not be created in this scenario. related bug: TS-1056 related checkin: 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 I also see this happening in on my forward proxy using Chrome: [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1950) tsxs should generate sample plugin codes
[
https://issues.apache.org/jira/browse/TS-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1950.
--
Resolution: Won't Fix
Fix Version/s: (was: sometime)
tsxs should generate sample plugin codes
Key: TS-1950
URL: https://issues.apache.org/jira/browse/TS-1950
Project: Traffic Server
Issue Type: New Feature
Components: Plugins
Reporter: Zhao Yongming
Apache Httpd ships the apxs2 with a `-g`, which will generate a new plugin
with the inline skeleton, we should implement that feature too.
{code}
apxs -n %NAME% -g
{code}
we need take care of the Global plugin and Remap plugin, :D
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-1945) connection collapsing should work in cluster wide
[ https://issues.apache.org/jira/browse/TS-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1945. -- Resolution: Won't Fix Fix Version/s: (was: 5.2.0) connection collapsing should work in cluster wide - Key: TS-1945 URL: https://issues.apache.org/jira/browse/TS-1945 Project: Traffic Server Issue Type: Improvement Components: Clustering, HTTP Reporter: Zhao Yongming Assignee: weijin the current read_while_writer does not work in cluster wide, we should improve it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1947) cache span code improvements
[ https://issues.apache.org/jira/browse/TS-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1947. -- Resolution: Duplicate Fix Version/s: (was: sometime) cache span code improvements Key: TS-1947 URL: https://issues.apache.org/jira/browse/TS-1947 Project: Traffic Server Issue Type: Bug Components: Cache, Core Reporter: James Peach Assignee: Phil Sorber After reviewing Store.cc, Phil and I had some ideas for improvements: - split the Span implementation out into I_Span.h and Span.cc - make Span::init() platform independent by adding a new ats_disk API in libts to wrap the platform dependencies of querying disk geometry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1956.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)
Under Heavy Load TS 3.3.4-dev can't (re)start
-
Key: TS-1956
URL: https://issues.apache.org/jira/browse/TS-1956
Project: Traffic Server
Issue Type: Bug
Reporter: Tommy Lee
Assignee: Bryan Call
Priority: Blocker
Labels: Crash
Attachments: backtrace.log
Hi,
We run TS in forward mode, under REALLY HEAVY load. Currently we run version
3.3.2-dev without problems.
But today, we tried to upgrade to version 3.3.4-dev without lucky.
We've noticed that, if TS restarts, it enters in this Segfault Loop.
Below are traffic.out logs with debug .*
I'll try to debug with GDB too, but I cannot stop this server for too long,
because of our operations.
Thanks in advance.
{code}
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fd9e0 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fdd00 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.81.5:46089 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.101.4:41361 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.156.38:59164 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c00] accepted connection from
10.202.81.5:46089 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.35.9:51533 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.201.20:10964 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
10.200.156.38:59164 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.148.2:44203 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fe020 on port 3128 as inbound transparent
[Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
10.202.101.4:41361 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015540] accepted connection from
10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
Segmentation fault
/usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
NOTE: Traffic Server received Sig 11: Segmentation fault
[Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
- STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.131.24:65434 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server].
[jira] [Updated] (TS-1964) Make Accept threads NUMA aware
[ https://issues.apache.org/jira/browse/TS-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1964: --- Fix Version/s: (was: sometime) 6.0.0 Make Accept threads NUMA aware -- Key: TS-1964 URL: https://issues.apache.org/jira/browse/TS-1964 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Labels: NUMA Fix For: 6.0.0 To work efficiently, we should have one (or several) accept threads per NUMA node. In addition, it should schedule the VCs on ET_NET threads that are assigned to the same NUMA node. This assures that memory allocated for the VC stays on the same NUMA node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1965) Make IO threads NUMA aware
[ https://issues.apache.org/jira/browse/TS-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1965: --- Fix Version/s: (was: sometime) 6.0.0 Make IO threads NUMA aware -- Key: TS-1965 URL: https://issues.apache.org/jira/browse/TS-1965 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Labels: NUMA Fix For: 6.0.0 To avoid cross QPI communications on systems with multiple NUMA nodes, it might make sense to have AIO threads assigned to NUMA nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1965) Make IO threads NUMA aware
[ https://issues.apache.org/jira/browse/TS-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1965: --- Assignee: Bryan Call Make IO threads NUMA aware -- Key: TS-1965 URL: https://issues.apache.org/jira/browse/TS-1965 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Labels: NUMA Fix For: 6.0.0 To avoid cross QPI communications on systems with multiple NUMA nodes, it might make sense to have AIO threads assigned to NUMA nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1967) create max accept handler function
[ https://issues.apache.org/jira/browse/TS-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-1967. -- Resolution: Incomplete Fix Version/s: (was: 6.0.0) Accept throttling seems like a good idea, but first we need a good design/requirements for the feature. create max accept handler function --- Key: TS-1967 URL: https://issues.apache.org/jira/browse/TS-1967 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.2.4 Reporter: Bin Chen Assignee: Bin Chen Labels: review Attachments: TS-1967.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1969) Mechanism to perform a graceful restart of trafficserver
[ https://issues.apache.org/jira/browse/TS-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1969: --- Fix Version/s: (was: 5.2.0) sometime Mechanism to perform a graceful restart of trafficserver Key: TS-1969 URL: https://issues.apache.org/jira/browse/TS-1969 Project: Traffic Server Issue Type: New Feature Reporter: Kris Lindgren Assignee: Phil Sorber Labels: A, C Fix For: sometime For example HAproxy has the ability to start a new HAproxy instance to tell the old one to temporarily disconnect from the socket so the new process can take it over. If startup was successful then new connections are handled by the new HAproxy instance and old connections are handled by the old HAproxy instance. Once all the old connections have finished the old instance terminates. I am currently using 3.2.4 and am trying to mitigate the breaking of existing connections when restarting. Specifically around adding a new SSL cert, but It would also be nice to mitigate breaking of connections when changing listen ports as well, or when you change certain configurations options that require a restart. I understand that the current 3.3.x branch should have a feature to re-read the ssl certs without requiring a restart. One possible issue with the above model is that the cache could only be owned by one process. It would be nice if the old process would degrade into read-only or a proxy-only mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-1973) need a regression test for TSNetAcceptNamedProtocol
[ https://issues.apache.org/jira/browse/TS-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1973: --- Assignee: Alan M. Carroll need a regression test for TSNetAcceptNamedProtocol --- Key: TS-1973 URL: https://issues.apache.org/jira/browse/TS-1973 Project: Traffic Server Issue Type: Test Components: Quality, TS API Reporter: James Peach Assignee: Alan M. Carroll Fix For: 5.2.0 We need a test for TSNetAcceptNamedProtocol so that we don't regress it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1969) Mechanism to perform a graceful restart of trafficserver
[ https://issues.apache.org/jira/browse/TS-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1969: --- Assignee: (was: Phil Sorber) Mechanism to perform a graceful restart of trafficserver Key: TS-1969 URL: https://issues.apache.org/jira/browse/TS-1969 Project: Traffic Server Issue Type: New Feature Reporter: Kris Lindgren Labels: A, C Fix For: sometime For example HAproxy has the ability to start a new HAproxy instance to tell the old one to temporarily disconnect from the socket so the new process can take it over. If startup was successful then new connections are handled by the new HAproxy instance and old connections are handled by the old HAproxy instance. Once all the old connections have finished the old instance terminates. I am currently using 3.2.4 and am trying to mitigate the breaking of existing connections when restarting. Specifically around adding a new SSL cert, but It would also be nice to mitigate breaking of connections when changing listen ports as well, or when you change certain configurations options that require a restart. I understand that the current 3.3.x branch should have a feature to re-read the ssl certs without requiring a restart. One possible issue with the above model is that the cache could only be owned by one process. It would be nice if the old process would degrade into read-only or a proxy-only mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1973) need a regression test for TSNetAcceptNamedProtocol
[ https://issues.apache.org/jira/browse/TS-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1973: Fix Version/s: (was: 5.2.0) 6.0.0 need a regression test for TSNetAcceptNamedProtocol --- Key: TS-1973 URL: https://issues.apache.org/jira/browse/TS-1973 Project: Traffic Server Issue Type: Test Components: Quality, TS API Reporter: James Peach Assignee: Joshua Blatt Fix For: 6.0.0 We need a test for TSNetAcceptNamedProtocol so that we don't regress it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1974) When proxy.config.log.logging_enabled set to 3, how close cacheurl.log?
[ https://issues.apache.org/jira/browse/TS-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1974: --- Fix Version/s: (was: 5.2.0) When proxy.config.log.logging_enabled set to 3, how close cacheurl.log? --- Key: TS-1974 URL: https://issues.apache.org/jira/browse/TS-1974 Project: Traffic Server Issue Type: Wish Components: Plugins Reporter: helaku When proxy.config.log.logging_enabled set to 3, how close cacheurl.log? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1974) When proxy.config.log.logging_enabled set to 3, how close cacheurl.log?
[ https://issues.apache.org/jira/browse/TS-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1974: --- Fix Version/s: Docs When proxy.config.log.logging_enabled set to 3, how close cacheurl.log? --- Key: TS-1974 URL: https://issues.apache.org/jira/browse/TS-1974 Project: Traffic Server Issue Type: Wish Components: Plugins Reporter: helaku Fix For: Docs When proxy.config.log.logging_enabled set to 3, how close cacheurl.log? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1974) When proxy.config.log.logging_enabled set to 3, how close cacheurl.log?
[ https://issues.apache.org/jira/browse/TS-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198798#comment-14198798 ] Susan Hinrichs commented on TS-1974: Seems to appear only the documentation. Feature does not seem to exist at this point in time. When proxy.config.log.logging_enabled set to 3, how close cacheurl.log? --- Key: TS-1974 URL: https://issues.apache.org/jira/browse/TS-1974 Project: Traffic Server Issue Type: Wish Components: Plugins Reporter: helaku Fix For: Docs When proxy.config.log.logging_enabled set to 3, how close cacheurl.log? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1975) LocalManager may cause manager crash
[
https://issues.apache.org/jira/browse/TS-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-1975.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
[~jamespeach] rewrote much of this, scenario should no be different.
LocalManager may cause manager crash
Key: TS-1975
URL: https://issues.apache.org/jira/browse/TS-1975
Project: Traffic Server
Issue Type: Bug
Components: Manager
Affects Versions: 3.3.4
Reporter: Zhao Yongming
Assignee: portl4t
Labels: Crash
when something wrong with the LocalManager, with
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104), then you
will get manager and server restart.
{code}
Jun 17 17:40:06 cache163 traffic_manager[25654]: {0x7f528b4297e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jun 17 17:40:06 cache163 traffic_manager[25654]: {0x7f528b4297e0} FATAL:
(last system error 104: Connection reset by peer)
Jun 17 17:40:06 cache163 traffic_manager[25654]: {0x7f528b4297e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jun 17 17:40:06 cache163 traffic_manager[25654]: {0x7f528b4297e0} ERROR:
(last system error 32: Broken pipe)
Jun 17 17:40:07 cache163 traffic_cop[25652]: cop received child status signal
[25654 2816]
Jun 17 17:40:07 cache163 traffic_cop[25652]: traffic_manager not running,
making sure traffic_server is dead
Jun 17 17:40:07 cache163 traffic_cop[25652]: spawning traffic_manager
Jun 17 17:40:07 cache163 traffic_manager[10118]: NOTE: --- Manager Starting
---
Jun 17 17:40:07 cache163 traffic_manager[10118]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.2.0 - (build # 51516 on Jun 15
2013 at 16:01:06)
Jun 17 17:40:07 cache163 traffic_manager[10118]: NOTE:
RLIMIT_NOFILE(7):cur(16),max(16)
Jun 17 17:40:07 cache163 traffic_manager[10118]: {0x7f26fc24a7e0} STATUS:
opened /var/log/trafficserver/manager.log
Jun 17 17:40:09 cache163 traffic_server[10131]: NOTE: --- Server Starting ---
Jun 17 17:40:09 cache163 traffic_server[10131]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 51516 on Jun 15 2013 at
16:01:31)
Jun 17 17:40:09 cache163 traffic_server[10131]: {0x2b167ded2280} STATUS:
opened /var/log/trafficserver/diags.log
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1979) Investigate body factory and its use of malloc()
[ https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1979: --- Fix Version/s: (was: sometime) 6.0.0 Investigate body factory and its use of malloc() Key: TS-1979 URL: https://issues.apache.org/jira/browse/TS-1979 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 It might be a nice optimization to make it use heap allocation (that is, put the body factory on the freelist) for small bodies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1980) Provide API for a plugin to also specify which body factory template to use for errors
[
https://issues.apache.org/jira/browse/TS-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1980:
---
Fix Version/s: (was: 5.2.0)
6.0.0
Provide API for a plugin to also specify which body factory template to use
for errors
--
Key: TS-1980
URL: https://issues.apache.org/jira/browse/TS-1980
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Leif Hedstrom
Fix For: 6.0.0
Right now, there are only two APIs that allows plugins to set the HTTP status
code and body message:
{code}
tsapi void TSHttpTxnSetHttpRetBody(TSHttpTxn txnp, const char* body_msg,
int plain_msg);
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus);
{code}
Since the body factory (templates) are now the only way to produce error
messages from within ATS itself, these APIs are now lacking a way to specify
which template to use. I imagine three possibilities (at least):
1) Make the last argument to TSHttpTxnSetHttpRetBody() be a multi-value
variable, with the semantics of
0 - body is HTML
1 - body is plain text
2 - body is a factory template name (e.g. access#denied or shrek#ogre).
This is probably pretty safe, but perhaps not super pretty.
2) Make TSHttpTxnSetHttpRetStatus() also take a body factory argument, e.g.
{code}
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus, const char* factory);
{code}
factory should probably be a string here, and not constants, because users
can put in arbitrary file names into the body factory. The string really is
the filename. This would break compatibility of the APIs I think.
3) We add a new API, e.g.
{code}
tsapi void TSHttpTxnSetHttpFactory(TSHttpTxn txnp, const char* factory);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1980) Provide API for a plugin to also specify which body factory template to use for errors
[
https://issues.apache.org/jira/browse/TS-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1980:
---
Assignee: Leif Hedstrom
Provide API for a plugin to also specify which body factory template to use
for errors
--
Key: TS-1980
URL: https://issues.apache.org/jira/browse/TS-1980
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.0.0
Right now, there are only two APIs that allows plugins to set the HTTP status
code and body message:
{code}
tsapi void TSHttpTxnSetHttpRetBody(TSHttpTxn txnp, const char* body_msg,
int plain_msg);
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus);
{code}
Since the body factory (templates) are now the only way to produce error
messages from within ATS itself, these APIs are now lacking a way to specify
which template to use. I imagine three possibilities (at least):
1) Make the last argument to TSHttpTxnSetHttpRetBody() be a multi-value
variable, with the semantics of
0 - body is HTML
1 - body is plain text
2 - body is a factory template name (e.g. access#denied or shrek#ogre).
This is probably pretty safe, but perhaps not super pretty.
2) Make TSHttpTxnSetHttpRetStatus() also take a body factory argument, e.g.
{code}
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus, const char* factory);
{code}
factory should probably be a string here, and not constants, because users
can put in arbitrary file names into the body factory. The string really is
the filename. This would break compatibility of the APIs I think.
3) We add a new API, e.g.
{code}
tsapi void TSHttpTxnSetHttpFactory(TSHttpTxn txnp, const char* factory);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1984) Allow for somewhat more flexible wildcards in remap.config
[
https://issues.apache.org/jira/browse/TS-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1984:
---
Fix Version/s: (was: 5.2.0)
6.0.0
Allow for somewhat more flexible wildcards in remap.config
--
Key: TS-1984
URL: https://issues.apache.org/jira/browse/TS-1984
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, HTTP
Reporter: Leif Hedstrom
Fix For: 6.0.0
Today, we support one wildcard mechanism, which is a catch-all:
{code}
map / http://www.example.com/
{code}
This is somewhat useful, but typically people end up using it together with
e.g. the regex-remap plugin to make it usable. I think a couple of small
additions would make it much better
1. Allow for wildcard by scheme (e.g. map http:/// and map https:///)
2. Allow for wildcards to restrict to port (e.g. map http:///:8080)
There is the regex_map that can maybe accomplish this, but it feels like if
we are supposed to have wildcards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1985) Eliminate built-in log formats in favor of logs_xml.config
[ https://issues.apache.org/jira/browse/TS-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1985: --- Labels: newbie (was: ) Eliminate built-in log formats in favor of logs_xml.config -- Key: TS-1985 URL: https://issues.apache.org/jira/browse/TS-1985 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Labels: newbie Fix For: 6.0.0 I have a feeling that the hardcoded (built-in) log-formats was the old way of doing things, and logs_xml.config is the new way. As such, I'd like to propose that we eliminate all the built-in's, and provide all those formats in a default logs_xml.config. One thing that might be necessary to add is an option in the XML config to disable a log file. I don't know if that's easily doable without using XML comments, but would be easy to add and useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1985) Eliminate built-in log formats in favor of logs_xml.config
[ https://issues.apache.org/jira/browse/TS-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-1985: --- Fix Version/s: (was: sometime) 6.0.0 Eliminate built-in log formats in favor of logs_xml.config -- Key: TS-1985 URL: https://issues.apache.org/jira/browse/TS-1985 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Labels: newbie Fix For: 6.0.0 I have a feeling that the hardcoded (built-in) log-formats was the old way of doing things, and logs_xml.config is the new way. As such, I'd like to propose that we eliminate all the built-in's, and provide all those formats in a default logs_xml.config. One thing that might be necessary to add is an option in the XML config to disable a log file. I don't know if that's easily doable without using XML comments, but would be easy to add and useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3171) tidy up Tokenizer interface
James Peach created TS-3171: --- Summary: tidy up Tokenizer interface Key: TS-3171 URL: https://issues.apache.org/jira/browse/TS-3171 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach Minor code improvements to tidy up the Tokenizer API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3171) tidy up Tokenizer interface
[ https://issues.apache.org/jira/browse/TS-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-3171: Priority: Trivial (was: Major) Fix Version/s: 5.2.0 Assignee: James Peach tidy up Tokenizer interface --- Key: TS-3171 URL: https://issues.apache.org/jira/browse/TS-3171 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach Assignee: James Peach Priority: Trivial Fix For: 5.2.0 Minor code improvements to tidy up the Tokenizer API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1992) examine mgmt/RecordsConfig.cc, add validation where it makes sense
[
https://issues.apache.org/jira/browse/TS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-1992:
---
Labels: newbie (was: )
examine mgmt/RecordsConfig.cc, add validation where it makes sense
--
Key: TS-1992
URL: https://issues.apache.org/jira/browse/TS-1992
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Labels: newbie
Fix For: 6.0.0
example:
{code}
{RECT_CONFIG, proxy.config.http.cache.required_headers, RECD_INT, 2,
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}
We should change this to
{code}
{RECT_CONFIG, proxy.config.http.cache.required_headers, RECD_INT, 2,
RECU_DYNAMIC, RR_NULL, RECC_NULL, [0-2], RECA_NULL}
{code}
which are the valid values for this config.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2004) Crash report: DLLRamCacheLRUEntry, RamCacheLRUEntry::Link_size_link::insert
[
https://issues.apache.org/jira/browse/TS-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-2004.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
Will reopen when/if this reappears.
Crash report: DLLRamCacheLRUEntry, RamCacheLRUEntry::Link_size_link::insert
-
Key: TS-2004
URL: https://issues.apache.org/jira/browse/TS-2004
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Labels: Crash
got an Ram cache LRU crash, log here for later follow up.
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x006d57e4 in DLLRamCacheLRUEntry,
RamCacheLRUEntry::Link_size_link::insert (this=0x2b37299087c8,
e=0x2b3714203e20, after=0x2b37299087e0) at ../../lib/ts/List.h:202
202 if (next(e)) prev(next(e)) = e;
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 keyutils-lib4
(gdb) bt
#0 0x006d57e4 in DLLRamCacheLRUEntry,
RamCacheLRUEntry::Link_size_link::insert (this=0x2b37299087c8,
e=0x2b3714203e20, after=0x2b37299087e0) at ../../lib/ts/List.h:202
#1 0x006d5443 in QueueRamCacheLRUEntry,
RamCacheLRUEntry::Link_size_link::insert (this=0x2b37299087c8,
e=0x2b3714203e20, after=0x2b37299087e0) at ../../lib/ts/List.h:244
#2 0x006d4d98 in QueueRamCacheLRUEntry,
RamCacheLRUEntry::Link_size_link::enqueue (this=0x2b37299087c8,
e=0x2b3714203e20) at ../../lib/ts/List.h:293
#3 0x006d4472 in RamCacheLRU::put (this=0x2b372c108780,
key=0x26b7500, data=0x2b38f8043370, len=2486330,
auxkey1=0, auxkey2=253484941) at RamCacheLRU.cc:198
#4 0x0069ec2b in CacheVC::handleReadDone (this=0x26b74c0,
event=3900, e=0x26b7648) at Cache.cc:2336
#5 0x004ed4a8 in Continuation::handleEvent (this=0x26b74c0,
event=3900, data=0x26b7648)
at ../iocore/eventsystem/I_Continuation.h:146
#6 0x006a479f in AIOCallbackInternal::io_complete (this=0x26b7648,
event=1, data=0x2b378001c720)
at ../../iocore/aio/P_AIO.h:80
#7 0x004ed4a8 in Continuation::handleEvent (this=0x26b7648, event=1,
data=0x2b378001c720)
at ../iocore/eventsystem/I_Continuation.h:146
#8 0x00713a4c in EThread::process_event (this=0x2b36e58f4010,
e=0x2b378001c720, calling_code=1)
at UnixEThread.cc:142
#9 0x00713c87 in EThread::execute (this=0x2b36e58f4010) at
UnixEThread.cc:193
#10 0x00712bfa in spawn_thread_internal (a=0x1cb2da0) at Thread.cc:88
#11 0x003d4b4077f1 in start_thread () from /lib64/libpthread.so.0
#12 0x003d4b0e570d in clone () from /lib64/libc.so.6
(gdb) l
197 DLLC,L::insert(C *e, C *after) {
198 if (!after) { push(e); return; }
199 prev(e) = after;
200 next(e) = next(after);
201 next(after) = e;
202 if (next(e)) prev(next(e)) = e;
203 }
204
205 //
206 // List descriptor for queue of objects of type C.
(gdb) p e
$1 = (RamCacheLRUEntry *) 0x2b3714203e20
(gdb) p *e
$2 = {key = {b = {2838449180001489673, 9234852465778727784}}, auxkey1 = 0,
auxkey2 = 253484941,
lru_link = {SLinkRamCacheLRUEntry = {next = 0x0}, prev =
0x2b375c28c510},
hash_link = {SLinkRamCacheLRUEntry = {next = 0x0}, prev = 0x0},
size_link = {SLinkRamCacheLRUEntry = {
next = 0xabcd1234}, prev = 0x2b37299087e0}, data = {m_ptr =
0x2b38f8043370}}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2006) TS cluster Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-2006.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.2.0)
Will reopen when/if reappears
TS cluster Segmentation fault
-
Key: TS-2006
URL: https://issues.apache.org/jira/browse/TS-2006
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Reporter: helaku
Assignee: portl4t
Labels: crash
% trafficserver show:version
traffic_server version --- 3.3.5-dev
traffic_manager version -- 3.3.5-dev
{code}
[TrafficServer] using root directory '/usr/local/trafficserver'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/trafficserver/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x33fe40eca0]
/usr/local/trafficserver/bin/traffic_server(HTTPInfo::set_buffer_reference(RefCountObj*)+0x2c)[0x5beacc]
/usr/local/trafficserver/bin/traffic_server(set_channel_data_ClusterFunction(ClusterHandler*,
void*, int)+0x115)[0x6389c5]
/usr/local/trafficserver/bin/traffic_server(ClusterHandler::process_set_data_msgs()+0x165)[0x61cb25]
/usr/local/trafficserver/bin/traffic_server(ClusterHandler::update_channels_read()+0x16)[0x622b66]
/usr/local/trafficserver/bin/traffic_server(ClusterHandler::process_read(long)+0x1c4)[0x623144]
/usr/local/trafficserver/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x179)[0x6277a9]
/usr/local/trafficserver/bin/traffic_server(ClusterState::IOComplete()+0xd2)[0x62ab82]
/usr/local/trafficserver/bin/traffic_server(ClusterState::doIO_read_event(int,
void*)+0xa1)[0x62afa1]
/usr/local/trafficserver/bin/traffic_server[0x6a25e1]
/usr/local/trafficserver/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x474)[0x69a304]
/usr/local/trafficserver/bin/traffic_server(EThread::process_event(Event*,
int)+0x238)[0x6c89f8]
/usr/local/trafficserver/bin/traffic_server(EThread::execute()+0x625)[0x6c9395]
/usr/local/trafficserver/bin/traffic_server[0x6c84be]
/lib64/libpthread.so.0[0x33fe40683d]
/lib64/libc.so.6(clone+0x6d)[0x33fd8d503d]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2009) Disallow \0 in all headers
[ https://issues.apache.org/jira/browse/TS-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-2009: --- Fix Version/s: (was: 5.2.0) 5.3.0 Disallow \0 in all headers -- Key: TS-2009 URL: https://issues.apache.org/jira/browse/TS-2009 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 5.3.0 Related to TS-1660, we should move the test for \0 in the Host: header to be generically applied when parsing all headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
