[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109022#comment-14109022
]
Nikolai Gorchilov commented on TS-3032:
---
* /proc/meminfo
{noformat}
MemTotal: 131999852 kB
MemFree:81857040 kB
Buffers: 357000 kB
Cached: 25975284 kB
SwapCached:0 kB
Active: 30757792 kB
Inactive: 15528096 kB
Active(anon): 19953648 kB
Inactive(anon): 292 kB
Active(file): 10804144 kB
Inactive(file): 15527804 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 1800 kB
Writeback: 0 kB
AnonPages: 19956200 kB
Mapped:47440 kB
Shmem: 332 kB
Slab:1794776 kB
SReclaimable: 990372 kB
SUnreclaim: 804404 kB
KernelStack:4872 kB
PageTables:43808 kB
NFS_Unstable: 0 kB
Bounce:0 kB
WritebackTmp: 0 kB
CommitLimit:6524 kB
Committed_AS: 17297316 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 488860 kB
VmallocChunk: 34290894976 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 2048 kB
DirectMap4k: 1125372 kB
DirectMap2M:93210624 kB
DirectMap1G:41943040 kB
{noformat}
* /proc//status
{noformat}
Name: [ET_NET 0]
State: S (sleeping)
Tgid: 24037
Pid:24037
PPid: 24025
TracerPid: 0
Uid:13 13 13 13
Gid:13 13 13 13
FDSize: 262144
Groups: 0
VmPeak: 25063316 kB
VmSize: 24999124 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 19672548 kB
VmRSS: 19672300 kB
VmData: 24902004 kB
VmStk: 136 kB
VmExe: 4100 kB
VmLib: 9684 kB
VmPTE: 39768 kB
VmSwap:0 kB
Threads:145
SigQ: 0/1031099
SigPnd:
ShdPnd:
SigBlk:
SigIgn: 00381000
SigCgt: 000180004e4f
CapInh:
CapPrm: 5402
CapEff: 5400
CapBnd: 001f
Seccomp:0
Cpus_allowed:
Cpus_allowed_list: 0-31
Mems_allowed: ,0003
Mems_allowed_list: 0-1
voluntary_ctxt_switches:130883732
nonvoluntary_ctxt_switches: 797084
{noformat}
* configure options
{noformat}
--with-group=proxy \
--with-xml=libxml2 \
--disable-static \
--disable-static-libts \
--disable-spdy \
--enable-interim-cache \
--enable-tproxy \
--enable-hwloc \
--enable-experimental-plugins \
--enable-example-plugins
{noformat}
* other system logs - nothing memory related available
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic
[jira] [Commented] (TS-2989) ats_speed: implement In-Place-Resource-Optimization flow
[ https://issues.apache.org/jira/browse/TS-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109114#comment-14109114 ] Otto van der Schaaf commented on TS-2989: - Working on this at https://github.com/apache/trafficserver/tree/oschaaf-ipro-flow Codewise it is ready, but I need to test it more thoroughly before committing it to master > ats_speed: implement In-Place-Resource-Optimization flow > > > Key: TS-2989 > URL: https://issues.apache.org/jira/browse/TS-2989 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Fix For: sometime > > > The PageSpeed optimization libraries also support a flow where images/js/css > can be optimized on the original url. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-3003) Remove overwriting of robots.txt in page speed plugin
[ https://issues.apache.org/jira/browse/TS-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf resolved TS-3003. - Resolution: Fixed > Remove overwriting of robots.txt in page speed plugin > - > > Key: TS-3003 > URL: https://issues.apache.org/jira/browse/TS-3003 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Christian Grobmeier >Assignee: Otto van der Schaaf > Fix For: 5.1.0 > > > Currently the page speed plugin overwrites /robots.txt with its own content. > This leads to problems in our setup, as Google cannot index our cached > website. > The following lines: > https://github.com/apache/trafficserver/blob/master/plugins/experimental/ats_speed/ats_resource_intercept.cc#L281-L286 > demonstrate how page speed subdues our own robots.txt and overwrites it with > own content for unknown reasons. > Also the second if/else can be removed as it currently has no further use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3003) Remove overwriting of robots.txt in page speed plugin
[ https://issues.apache.org/jira/browse/TS-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109116#comment-14109116 ] Otto van der Schaaf commented on TS-3003: - This is fixed via 335cbf4100e79c9333a4a4d06cce1d17149c4935 on master (5.1.x too via afa93fa9277f0cab6446b46b782971c88bfdb8ef) Changing fix version to 5.1.x and marking as resolved. > Remove overwriting of robots.txt in page speed plugin > - > > Key: TS-3003 > URL: https://issues.apache.org/jira/browse/TS-3003 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Christian Grobmeier >Assignee: Otto van der Schaaf > Fix For: 5.1.0 > > > Currently the page speed plugin overwrites /robots.txt with its own content. > This leads to problems in our setup, as Google cannot index our cached > website. > The following lines: > https://github.com/apache/trafficserver/blob/master/plugins/experimental/ats_speed/ats_resource_intercept.cc#L281-L286 > demonstrate how page speed subdues our own robots.txt and overwrites it with > own content for unknown reasons. > Also the second if/else can be removed as it currently has no further use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3003) Remove overwriting of robots.txt in page speed plugin
[ https://issues.apache.org/jira/browse/TS-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf updated TS-3003: Fix Version/s: (was: 5.2.0) 5.1.0 > Remove overwriting of robots.txt in page speed plugin > - > > Key: TS-3003 > URL: https://issues.apache.org/jira/browse/TS-3003 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Christian Grobmeier >Assignee: Otto van der Schaaf > Fix For: 5.1.0 > > > Currently the page speed plugin overwrites /robots.txt with its own content. > This leads to problems in our setup, as Google cannot index our cached > website. > The following lines: > https://github.com/apache/trafficserver/blob/master/plugins/experimental/ats_speed/ats_resource_intercept.cc#L281-L286 > demonstrate how page speed subdues our own robots.txt and overwrites it with > own content for unknown reasons. > Also the second if/else can be removed as it currently has no further use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2993) ats_speed: update towards 1.8.31.4-stable
[ https://issues.apache.org/jira/browse/TS-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109117#comment-14109117 ] Otto van der Schaaf commented on TS-2993: - This is fixed via 335cbf4100e79c9333a4a4d06cce1d17149c4935 on master (5.1.x too via afa93fa9277f0cab6446b46b782971c88bfdb8ef) Changing fix version to 5.1.x and marking as resolved. > ats_speed: update towards 1.8.31.4-stable > - > > Key: TS-2993 > URL: https://issues.apache.org/jira/browse/TS-2993 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Fix For: sometime > > > A new stable mod_pagespeed release was announced yesterday[1]. > Upgrade ats_speed to use the latest and greatest stable PageSpeed > optimization libraries. > [1] > https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mod-pagespeed-discuss/Qng-Da0IwcY/Y63-WlDHg5wJ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2989) ats_speed: implement In-Place-Resource-Optimization flow
[ https://issues.apache.org/jira/browse/TS-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf updated TS-2989: Fix Version/s: (was: sometime) 5.1.1 > ats_speed: implement In-Place-Resource-Optimization flow > > > Key: TS-2989 > URL: https://issues.apache.org/jira/browse/TS-2989 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Fix For: 5.1.1 > > > The PageSpeed optimization libraries also support a flow where images/js/css > can be optimized on the original url. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2993) ats_speed: update towards 1.8.31.4-stable
[ https://issues.apache.org/jira/browse/TS-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf updated TS-2993: Fix Version/s: (was: sometime) 5.1.0 > ats_speed: update towards 1.8.31.4-stable > - > > Key: TS-2993 > URL: https://issues.apache.org/jira/browse/TS-2993 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Fix For: 5.1.0 > > > A new stable mod_pagespeed release was announced yesterday[1]. > Upgrade ats_speed to use the latest and greatest stable PageSpeed > optimization libraries. > [1] > https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mod-pagespeed-discuss/Qng-Da0IwcY/Y63-WlDHg5wJ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2993) ats_speed: update towards 1.8.31.4-stable
[ https://issues.apache.org/jira/browse/TS-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otto van der Schaaf resolved TS-2993. - Resolution: Fixed > ats_speed: update towards 1.8.31.4-stable > - > > Key: TS-2993 > URL: https://issues.apache.org/jira/browse/TS-2993 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Otto van der Schaaf >Assignee: Otto van der Schaaf > Fix For: 5.1.0 > > > A new stable mod_pagespeed release was announced yesterday[1]. > Upgrade ats_speed to use the latest and greatest stable PageSpeed > optimization libraries. > [1] > https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mod-pagespeed-discuss/Qng-Da0IwcY/Y63-WlDHg5wJ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109133#comment-14109133
]
Zhao Yongming commented on TS-3032:
---
looks nothing unusal, I think that 'Cached: 25975284 kB' is caused by
the access logging, then we need more infomation on ATS:
1. your ram cache setting: proxy.config.cache.ram_cache.size, if not set please
tell us your storage device usage, and cache min_average_object_size.
2. let us dump some memory details in the ATS itself:
https://docs.trafficserver.apache.org/en/latest/sdk/troubleshooting-tips/debugging-memory-leaks.en.html
and we should better get all those data the breaking point too :D
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x180)[0x59b070]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x173)[0x57bbb3]
> /z/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x616)[0x6d65a6]
> /z/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xb0)[0x6b1af0]
> /z/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x83)[0x57c2d3]
> /z/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x58baeb]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x888)[0x5a0b78]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x7e2)[0x5a0ad2]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/cacheurl.so(+0x17dc)[0x2b6263a477dc]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/tslua.so(+0x596f)[0x2b626363396f]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/stats_over_http.so(+0x1235)[0x2b6263228235]
> /z/bin/traffic_server(HttpSM::state_api_call
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109151#comment-14109151
]
Nikolai Gorchilov commented on TS-3032:
---
* traffic_line -r proxy.config.cache.ram_cache.size
{noformat}
1073741824
{noformat}
* traffic_line -s proxy.config.dump_mem_info_frequency -v 60
{noformat}
allocated |in-use | type size | free list name
|||--
67108864 | 0 |2097152 |
memory/ioBufAllocator[14]
268435456 | 80740352 |1048576 |
memory/ioBufAllocator[13]
83886080 |7340032 | 524288 |
memory/ioBufAllocator[12]
218103808 | 11272192 | 262144 |
memory/ioBufAllocator[11]
88080384 |9568256 | 131072 |
memory/ioBufAllocator[10]
243269632 | 36831232 | 65536 | memory/ioBufAllocator[9]
2797600768 | 2661744640 | 32768 | memory/ioBufAllocator[8]
443547648 | 184287232 | 16384 | memory/ioBufAllocator[7]
612630528 | 525918208 | 8192 | memory/ioBufAllocator[6]
1208483840 | 905179136 | 4096 | memory/ioBufAllocator[5]
4456448 |4358144 | 2048 | memory/ioBufAllocator[4]
1179648 |1078272 | 1024 | memory/ioBufAllocator[3]
9043968 |9004032 |512 | memory/ioBufAllocator[2]
4521984 |1761536 |256 | memory/ioBufAllocator[1]
39108608 |1824768 |128 | memory/ioBufAllocator[0]
120840192 | 249408 | 96 | memory/eventAllocator
10270720 |7616480 | 80 | memory/mutexAllocator
46039040 | 17172480 | 64 | memory/ioBlockAllocator
28323840 | 20658912 | 48 | memory/ioDataAllocator
55449600 | 40364640 |240 | memory/ioAllocator
0 | 0 |384 | memory/socksAllocator
0 | 0 |128 |
memory/udpReadContAllocator
0 | 0 |160 |
memory/udpPacketAllocator
105627648 | 71248800 |672 | memory/netVCAllocator
0 | 0 |128 |
memory/UDPIOEventAllocator
92160 | 68400 |720 | memory/sslNetVCAllocator
0 | 0 | 64 | memory/RamCacheLRUEntry
32526336 | 32181984 | 96 |
memory/RamCacheCLFUSEntry
1454080 |1420640 |160 | memory/openDirEntry
14336 | 0 |112 |
memory/migrateToInterimCache
0 | 0 | 48 | memory/evacuationKey
6144 | 0 | 48 | memory/cacheRemoveCont
10936320 | 10875648 | 96 | memory/evacuationBlock
11673600 | 11447040 |960 | memory/cacheVConnection
0 | 0 | 32 | memory/byteBankAllocator
0 | 0 |592 |
memory/clusterVCAllocator
0 | 0 |112 |
memory/inControlAllocator
0 | 0 |112 |
memory/outControlAllocator
0 | 0 | 48 |
memory/ClusterVConnectionCache::Entry
0 | 0 |576 |
memory/cacheContAllocator
0 | 0 | 16 |
memory/DNSRequestDataAllocator
1354240 | 33856 | 33856 | memory/dnsBufAllocator
1146880 | 20480 | 1280 | memory/dnsEntryAllocator
24477696 | 73728 | 2304 |
memory/hostDBContAllocator
0 | 0 |112 |
memory/OneWayTunnelAllocator
168034304 | 47165440 | 2048 | memory/hdrStrHeap
217841664 | 75976704 | 2048 | memory/hdrHeap
229376 | 70400 |256 |
memory/httpCacheAltAllocator
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |144 |
memory/CongestionDBContAllocator
0 | 0 |128 | memory/RemapPluginsAlloc
0 | 0 | 7760 |
memory/httpUpdateSMAllocator
0 | 0 | 48 |
memory/CacheLookupHttpConfigAllocator
13848576 |9485280 |224 |
memory/httpServerSess
[jira] [Created] (TS-3038) Deletion of iterator in middle of iteration
Alan M. Carroll created TS-3038:
---
Summary: Deletion of iterator in middle of iteration
Key: TS-3038
URL: https://issues.apache.org/jira/browse/TS-3038
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Alan M. Carroll
Trie::Clear iterates over its list of values but calls {{delete}} on the
iterator which is potentially broken. This is exactly the same issue as TS-2396
and should probably be fixed in the same way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109214#comment-14109214
]
Zhao Yongming commented on TS-3032:
---
well, you have 7368964608 memory in the freelist, and 4893378608 in use, that
is 66% in use. with about 8000 active connections. all sounds not so bad except
that 7G is far smaller than that 19G from the pid summary, why?
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x180)[0x59b070]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x173)[0x57bbb3]
> /z/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x616)[0x6d65a6]
> /z/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xb0)[0x6b1af0]
> /z/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x83)[0x57c2d3]
> /z/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x58baeb]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x888)[0x5a0b78]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x7e2)[0x5a0ad2]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/cacheurl.so(+0x17dc)[0x2b6263a477dc]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/tslua.so(+0x596f)[0x2b626363396f]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/stats_over_http.so(+0x1235)[0x2b6263228235]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x22b)[0x59270b]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_se
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109216#comment-14109216
]
Zhao Yongming commented on TS-3032:
---
I'd like you keep colect those data for some more days, the same time(to get
the same load) if you can, to figure out which component is wasting more
memories.
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x180)[0x59b070]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x173)[0x57bbb3]
> /z/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x616)[0x6d65a6]
> /z/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xb0)[0x6b1af0]
> /z/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x83)[0x57c2d3]
> /z/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x58baeb]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x888)[0x5a0b78]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x7e2)[0x5a0ad2]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/cacheurl.so(+0x17dc)[0x2b6263a477dc]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/tslua.so(+0x596f)[0x2b626363396f]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/stats_over_http.so(+0x1235)[0x2b6263228235]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x22b)[0x59270b]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server[0x714a60]
> /z/bin/traffic_server(NetHandler::mainNetEvent
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109225#comment-14109225
]
Zhao Yongming commented on TS-3032:
---
and if you have more than one boxes with that issue, please consider test one
box with the following tweak:
1. re-install with reclaim freelist enabled. and make sure reclaim is enabled
in the records.config
2. use the standard LRU: set proxy.config.cache.ram_cache.algorithm to 1
and if you have more system that can do a release test, we can identify which
release is proved to be correct. :D
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x180)[0x59b070]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x173)[0x57bbb3]
> /z/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x616)[0x6d65a6]
> /z/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xb0)[0x6b1af0]
> /z/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x83)[0x57c2d3]
> /z/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x58baeb]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x888)[0x5a0b78]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x7e2)[0x5a0ad2]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/cacheurl.so(+0x17dc)[0x2b6263a477dc]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/tslua.so(+0x596f)[0x2b626363396f]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/stats_over_http.so(+0x1235)[0x2b6263228235]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffi
[jira] [Created] (TS-3039) OCSP stapling memory leaks
James Peach created TS-3039:
---
Summary: OCSP stapling memory leaks
Key: TS-3039
URL: https://issues.apache.org/jira/browse/TS-3039
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: James Peach
I enabled OCSP with a self-signed certificate (ie. a simple one that doesn't
have OCSP issuer information in it.).
{code}
Process: traffic_server [7506]
Path:/opt/ats/bin/traffic_server
Load Address:0x10a52d000
Identifier: traffic_server
Version: 0
Code Type: X86-64
Parent Process: bash [7289]
Date/Time: 2014-08-25 09:03:27.837 -0700
OS Version: Mac OS X 10.9.4 (13E28)
Report Version: 7
leaks Report Version: 2.0
Process 7506: 81597 nodes malloced for 54675 KB
Process 7506: 61 leaks for 2880 total leaked bytes.
Leak: 0x7fc5ba5091f0 size=112 zone: DefaultMallocZone_0xa643000
0x0b3ed6c0 0x0001 0x 0x ..>.
0x 0x 0x0001 0x0001
0x 0x 0x 0x
0x7115f3d0 0x7fff 0x 0x ...q
0x 0x 0x0001 0x
0x 0x 0x 0x
0x 0x 0x 0x2000 ...
Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
SSLCertificateConfig::startup() SSLConfig.cc:326 |
SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
SSLUtils.cc:1552 | ssl_store_ssl_context(SSLConfigParams const*,
SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:111 |
BIO_new_file | BIO_new | CRYPTO_malloc | ats_malloc ink_memory.cc:50 | malloc |
malloc_zone_malloc
Leak: 0x7fc5bc8f7900 size=32 zone: DefaultMallocZone_0xa643000
0x0f301131 0x04550306 0x74080c03 0x2e747365 1.0...Utest.
0x006d6f63 0x 0x 0x com.
Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
SSLCertificateConfig::startup() SSLConfig.cc:326 |
SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
SSLUtils.cc:1531 | ssl_store_ssl_context(SSLConfigParams const*,
SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:113 |
PEM_ASN1_read_bio | d2i_X509_AUX | ASN1_item_d2i | ASN1_item_ex_d2i |
asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
x509_name_ex_d2i | x509_name_canon | CRYPTO_malloc | ats_malloc
ink_memory.cc:50 | malloc | malloc_zone_malloc
Leak: 0x7fc5bc8f7920 size=48 zone: DefaultMallocZone_0xa643000
0x 0x 0x 0x
0x 0x0003 0xbcb19af0 0x7fc5
0x0009 0x46455141 0x77415142 0x00035452 AQEFBQAwRT..
Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
SSLCertificateConfig::startup() SSLConfig.cc:326 |
SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
SSLUtils.cc:1531 | ssl_store_ssl_context(SSLConfigParams const*,
SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:113 |
PEM_ASN1_read_bio | d2i_X509_AUX | ASN1_item_d2i | ASN1_item_ex_d2i |
asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
asn1_d2i_ex_primitive | asn1_ex_c2i | c2i_ASN1_OBJECT | ASN1_OBJECT_new |
CRYPTO_malloc | ats_malloc ink_memory.cc:50 | malloc | malloc_zone_malloc
Leak: 0x7fc5bc8f8ed0 size=48 zone: DefaultMallocZone_0xa643000
0x 0x 0x 0x
0x 0x0009 0xbc8f8f00 0x7fc5
0x0009 0x 0x 0x
Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
SSLCertificateConfig::startup() SSLConfig.cc:326 |
SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
SSLParseCertificateConfiguration(SSLConfigParams co
[jira] [Commented] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109248#comment-14109248
]
Alan M. Carroll commented on TS-3022:
-
I used the settings for OCSP but I'm not seeing the double free. Are their any
other settings needed?
> OCSP double free or corruption (!prev)
> --
>
> Key: TS-3022
> URL: https://issues.apache.org/jira/browse/TS-3022
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Blocker
> Fix For: 5.1.0
>
>
> Centos 6 x86_64 gitmaster
> Enable ocsp
> config set
> {code}
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> CONFIG proxy.config.ssl.ocsp.update_period INT 60
> {code}
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (!prev): 0x02af8be0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
> /lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
> /usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
> /usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
> /usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
> /usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
> /usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
> /usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
> /usr/bin/traffic_server[0x73eb5a]
> /lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-289) should we get rid of type index?
[ https://issues.apache.org/jira/browse/TS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach closed TS-289. -- Resolution: Invalid AFAICT this document doesn't exist any more. > should we get rid of type index? > > > Key: TS-289 > URL: https://issues.apache.org/jira/browse/TS-289 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Miles Libbey > Fix For: Docs > > > http://incubator.apache.org/trafficserver/docs/v2/sdk/TypeIndex.html > seems pretty worthless, and unlikely anyone will maintain. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2409) Authproxy plugin is not documented
[ https://issues.apache.org/jira/browse/TS-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach closed TS-2409. --- Resolution: Fixed https://docs.trafficserver.apache.org/en/latest/reference/plugins/authproxy.en.html > Authproxy plugin is not documented > -- > > Key: TS-2409 > URL: https://issues.apache.org/jira/browse/TS-2409 > Project: Traffic Server > Issue Type: Bug > Components: Documentation, Plugins >Reporter: Igor Galić > Fix For: Docs > > > While experimental, I am sure it does the authproxy plugin's wide-spread use > (or at least test) if it is not documented. > We should change that. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2571) Describe directory structure in docs
[ https://issues.apache.org/jira/browse/TS-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2571. - Resolution: Fixed This looks done to me. > Describe directory structure in docs > > > Key: TS-2571 > URL: https://issues.apache.org/jira/browse/TS-2571 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Miles Libbey > Fix For: Docs > > > It doesn't appear that we describe the directory structure for users in the > documentation -- eg, where do I find config files? Where do I find tools? > While we can't say definitively the absolute path, we could describe the > defaults. > For instance, in admin/getting-started.en.html we could tell users where to > look for configurations files and tools. Similarly, in each of the files in > doc/reference/configuration, seems like there should be a sentence about > where to find the file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2734) The development process docs is not up to date
[ https://issues.apache.org/jira/browse/TS-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-2734: --- Assignee: Leif Hedstrom > The development process docs is not up to date > -- > > Key: TS-2734 > URL: https://issues.apache.org/jira/browse/TS-2734 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: Docs > > > https://cwiki.apache.org/confluence/display/TS/Development+Process > The back port section is definitely out of date, and maybe other areas too. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109294#comment-14109294
]
Nikolai Gorchilov commented on TS-3032:
---
Yes, I have two boxes that have this issue and one of them is available for
testing. Have in mind it has just 48G of RAM.
Here's the relevant info on this box just after restarting the new build of
traffic server with requested config changes:
* cat /proc/meminfo
{noformat}
MemTotal: 49361540 kB
MemFree:36481844 kB
MemAvailable: 37318832 kB
Buffers: 139888 kB
Cached: 1174072 kB
SwapCached:0 kB
Active: 11619048 kB
Inactive: 472492 kB
Active(anon): 10944848 kB
Inactive(anon):43404 kB
Active(file): 674200 kB
Inactive(file): 429088 kB
Unevictable: 175688 kB
Mlocked: 12852 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 10953252 kB
Mapped:61956 kB
Shmem: 44052 kB
Slab: 513432 kB
SReclaimable: 143176 kB
SUnreclaim: 370256 kB
KernelStack:7728 kB
PageTables:29912 kB
NFS_Unstable: 0 kB
Bounce:0 kB
WritebackTmp: 0 kB
CommitLimit:24680768 kB
Committed_AS: 11943052 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 285388 kB
VmallocChunk: 34359406432 kB
AnonHugePages: 10416128 kB
DirectMap4k: 13824 kB
DirectMap2M: 4171776 kB
DirectMap1G:48234496 kB
{noformat}
* /proc//status after traffic_server restart
{noformat}
Name: [ET_NET 0]
State: S (sleeping)
Tgid: 24406
Ngid: 0
Pid:24406
PPid: 24397
TracerPid: 0
Uid:13 13 13 13
Gid:13 13 13 13
FDSize: 128
Groups: 0
VmPeak: 19229780 kB
VmSize: 19229272 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 10616928 kB
VmRSS: 10616928 kB
VmData: 19129068 kB
VmStk: 136 kB
VmExe: 4096 kB
VmLib: 10736 kB
VmPTE: 21840 kB
VmSwap:0 kB
Threads:162
SigQ: 0/192701
SigPnd:
ShdPnd:
SigBlk:
SigIgn: 00381000
SigCgt: 000180004e4f
CapInh:
CapPrm: 5402
CapEff: 5400
CapBnd: 001f
Cpus_allowed:
Cpus_allowed_list: 0-15
voluntary_ctxt_switches:26618
nonvoluntary_ctxt_switches: 135
{noformat}
* relevant records.config options:
{noformat}
CONFIG proxy.config.allocator.enable_reclaim INT 1
CONFIG proxy.config.cache.ram_cache_cutoff INT 65536
CONFIG proxy.config.cache.ram_cache.size INT 1073741824
CONFIG proxy.config.cache.ram_cache.algorithm INT 1
{noformat}
NB! Could it be related to ram_cache_cutoff? Seems all crashes are for
allocations above 64k.
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Fix For: 5.2.0
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x2
[jira] [Closed] (TS-1552) add WCCP documentation to administration guide
[ https://issues.apache.org/jira/browse/TS-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach closed TS-1552. --- Resolution: Fixed https://docs.trafficserver.apache.org/en/latest/admin/transparent-proxy/wccp-configuration.en.html > add WCCP documentation to administration guide > -- > > Key: TS-1552 > URL: https://issues.apache.org/jira/browse/TS-1552 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Peach > Fix For: Docs > > > It looks like amc wrote some WCCP documentation, > http://people.apache.org/~amc/tiphares/wccp-configuration.html. We should > integrate this into the main admin docs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-3040) Remove obsolete traffic_shell docs
[ https://issues.apache.org/jira/browse/TS-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3040: - Assignee: Leif Hedstrom > Remove obsolete traffic_shell docs > -- > > Key: TS-3040 > URL: https://issues.apache.org/jira/browse/TS-3040 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > > There's two categories of docs here to consider for removal: > 1) The docs and references to traffic_shell. > 2) The various man pages for show_* commands. > I left this in place, because when the plan to nuke traffic_shell was > discussed, there was opposition to its removal. So a Perl script was > implemented to replace traffic_shell, but at this point, no one cared any > more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-3040) Remove obsolete traffic_shell docs
Leif Hedstrom created TS-3040: - Summary: Remove obsolete traffic_shell docs Key: TS-3040 URL: https://issues.apache.org/jira/browse/TS-3040 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Leif Hedstrom There's two categories of docs here to consider for removal: 1) The docs and references to traffic_shell. 2) The various man pages for show_* commands. I left this in place, because when the plan to nuke traffic_shell was discussed, there was opposition to its removal. So a Perl script was implemented to replace traffic_shell, but at this point, no one cared any more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3040) Remove obsolete traffic_shell docs
[ https://issues.apache.org/jira/browse/TS-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3040: -- Fix Version/s: Docs > Remove obsolete traffic_shell docs > -- > > Key: TS-3040 > URL: https://issues.apache.org/jira/browse/TS-3040 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: Docs > > > There's two categories of docs here to consider for removal: > 1) The docs and references to traffic_shell. > 2) The various man pages for show_* commands. > I left this in place, because when the plan to nuke traffic_shell was > discussed, there was opposition to its removal. So a Perl script was > implemented to replace traffic_shell, but at this point, no one cared any > more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3040) Remove obsolete traffic_shell docs
[ https://issues.apache.org/jira/browse/TS-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109349#comment-14109349 ] ASF subversion and git services commented on TS-3040: - Commit e9c202eaa5d49a3e7665fc71c1030cc6a5b90bc3 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e9c202e ] TS-3040 Remove some obsolete traffic_shell references / docs / files > Remove obsolete traffic_shell docs > -- > > Key: TS-3040 > URL: https://issues.apache.org/jira/browse/TS-3040 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: Docs > > > There's two categories of docs here to consider for removal: > 1) The docs and references to traffic_shell. > 2) The various man pages for show_* commands. > I left this in place, because when the plan to nuke traffic_shell was > discussed, there was opposition to its removal. So a Perl script was > implemented to replace traffic_shell, but at this point, no one cared any > more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3038) Deletion of iterator in middle of iteration
[
https://issues.apache.org/jira/browse/TS-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3038:
--
Fix Version/s: 5.2.0
> Deletion of iterator in middle of iteration
> ---
>
> Key: TS-3038
> URL: https://issues.apache.org/jira/browse/TS-3038
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
> Fix For: 5.2.0
>
>
> Trie::Clear iterates over its list of values but calls {{delete}} on the
> iterator which is potentially broken. This is exactly the same issue as
> TS-2396 and should probably be fixed in the same way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3036) Add logging field to define the cache medium used to serve a HIT
[ https://issues.apache.org/jira/browse/TS-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3036: -- Fix Version/s: sometime > Add logging field to define the cache medium used to serve a HIT > > > Key: TS-3036 > URL: https://issues.apache.org/jira/browse/TS-3036 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Ryan Frantz > Fix For: sometime > > > I want to be able to differentiate between RAM cache HITs and disk cache > HITs. Add a logging field to inform the administrator if the HIT came from > RAM, at least. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3037) Support Setting Of Priority Code Point (PCP) Per IEEE_802.1Q
[ https://issues.apache.org/jira/browse/TS-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3037: -- Fix Version/s: sometime > Support Setting Of Priority Code Point (PCP) Per IEEE_802.1Q > > > Key: TS-3037 > URL: https://issues.apache.org/jira/browse/TS-3037 > Project: Traffic Server > Issue Type: New Feature >Reporter: Jason Strongman > Fix For: sometime > > > Modify ATS to allow setting another socket option, SO_PRIORITY. > This parameter should be set on new connections created by ATS. The parameter > should also be set on responses back to clients. > This parameter should also be set based on request or response conditions. So > preferably allowing the parameter to be defined within the header_rewrite or > lua plugins. > This parameter should only impact layer 2 and should have no impacts on the > layer 3 DSCP values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3039) OCSP stapling memory leaks
[
https://issues.apache.org/jira/browse/TS-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3039:
--
Fix Version/s: 5.2.0
> OCSP stapling memory leaks
> --
>
> Key: TS-3039
> URL: https://issues.apache.org/jira/browse/TS-3039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Reporter: James Peach
> Fix For: 5.2.0
>
>
> I enabled OCSP with a self-signed certificate (ie. a simple one that doesn't
> have OCSP issuer information in it.).
> {code}
> Process: traffic_server [7506]
> Path:/opt/ats/bin/traffic_server
> Load Address:0x10a52d000
> Identifier: traffic_server
> Version: 0
> Code Type: X86-64
> Parent Process: bash [7289]
> Date/Time: 2014-08-25 09:03:27.837 -0700
> OS Version: Mac OS X 10.9.4 (13E28)
> Report Version: 7
> leaks Report Version: 2.0
> Process 7506: 81597 nodes malloced for 54675 KB
> Process 7506: 61 leaks for 2880 total leaked bytes.
> Leak: 0x7fc5ba5091f0 size=112 zone: DefaultMallocZone_0xa643000
> 0x0b3ed6c0 0x0001 0x 0x ..>.
> 0x 0x 0x0001 0x0001
> 0x 0x 0x 0x
> 0x7115f3d0 0x7fff 0x 0x ...q
> 0x 0x 0x0001 0x
> 0x 0x 0x 0x
> 0x 0x 0x 0x2000 ...
> Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
> SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
> SSLCertificateConfig::startup() SSLConfig.cc:326 |
> SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
> SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
> SSLUtils.cc:1552 | ssl_store_ssl_context(SSLConfigParams const*,
> SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
> ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:111 |
> BIO_new_file | BIO_new | CRYPTO_malloc | ats_malloc ink_memory.cc:50 | malloc
> | malloc_zone_malloc
> Leak: 0x7fc5bc8f7900 size=32 zone: DefaultMallocZone_0xa643000
> 0x0f301131 0x04550306 0x74080c03 0x2e747365 1.0...Utest.
> 0x006d6f63 0x 0x 0x com.
> Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
> SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
> SSLCertificateConfig::startup() SSLConfig.cc:326 |
> SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
> SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
> SSLUtils.cc:1531 | ssl_store_ssl_context(SSLConfigParams const*,
> SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
> ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:113 |
> PEM_ASN1_read_bio | d2i_X509_AUX | ASN1_item_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> x509_name_ex_d2i | x509_name_canon | CRYPTO_malloc | ats_malloc
> ink_memory.cc:50 | malloc | malloc_zone_malloc
> Leak: 0x7fc5bc8f7920 size=48 zone: DefaultMallocZone_0xa643000
> 0x 0x 0x 0x
> 0x 0x0003 0xbcb19af0 0x7fc5
> 0x0009 0x46455141 0x77415142 0x00035452 AQEFBQAwRT..
> Call stack: [thread 0x7fff727e3310]: | start | main Main.cc:1568 |
> SSLNetProcessor::start(int, unsigned long) SSLNetProcessor.cc:71 |
> SSLCertificateConfig::startup() SSLConfig.cc:326 |
> SSLCertificateConfig::reconfigure() SSLConfig.cc:342 |
> SSLParseCertificateConfiguration(SSLConfigParams const*, SSLCertLookup*)
> SSLUtils.cc:1531 | ssl_store_ssl_context(SSLConfigParams const*,
> SSLCertLookup*, ssl_user_config const&) SSLUtils.cc:1395 |
> ssl_stapling_init_cert(ssl_ctx_st*, char const*) OCSPStapling.cc:113 |
> PEM_ASN1_read_bio | d2i_X509_AUX | ASN1_item_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_template_ex_d2i | asn1_template_noexp_d2i | ASN1_item_ex_d2i |
> asn1_d2i_ex_primitive | asn1_ex_c2i | c2i_ASN1_OBJECT | ASN1_OBJECT_new |
> CRYPTO_malloc | ats_malloc ink_memory.cc:50 | malloc | malloc_zone_malloc
> Leak: 0x7fc5bc8f8ed0 size=48 zone: DefaultMallocZone_0xa643000
> 0x 0x 0x 0x
> 0x 0x0009 0xbc8f8f00 0x7fc5
> 0x0009 0x 0x 0x ...
[jira] [Commented] (TS-3037) Support Setting Of Priority Code Point (PCP) Per IEEE_802.1Q
[ https://issues.apache.org/jira/browse/TS-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109357#comment-14109357 ] Leif Hedstrom commented on TS-3037: --- Marking for sometime, until someone says she will work on this. > Support Setting Of Priority Code Point (PCP) Per IEEE_802.1Q > > > Key: TS-3037 > URL: https://issues.apache.org/jira/browse/TS-3037 > Project: Traffic Server > Issue Type: New Feature >Reporter: Jason Strongman > Fix For: sometime > > > Modify ATS to allow setting another socket option, SO_PRIORITY. > This parameter should be set on new connections created by ATS. The parameter > should also be set on responses back to clients. > This parameter should also be set based on request or response conditions. So > preferably allowing the parameter to be defined within the header_rewrite or > lua plugins. > This parameter should only impact layer 2 and should have no impacts on the > layer 3 DSCP values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3029) ats-5.0.1 crash when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3029:
--
Fix Version/s: 5.2.0
> ats-5.0.1 crash when SPDY enabled
> -
>
> Key: TS-3029
> URL: https://issues.apache.org/jira/browse/TS-3029
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Wei Sun
> Labels: yahoo
> Fix For: 5.2.0
>
>
> {code}
> #0 0x006200ba in std::vector std::char_traits, std::allocator >, std::basic_string std::char_traits, std::allocator > >,
> std::allocator,
> std::allocator >, std::basic_string,
> std::allocator > > > >::size (this=0x38)
> at
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_vector.h:533
> #1 0x0061e386 in spdy_prepare_status_response (sm=0x2b90b68a5d90,
> stream_id=103, status=0x792cad "500 Internal Server Error") at
> SpdyCallbacks.cc:57
> #2 0x0061b4ef in spdy_process_fetch (event=TS_EVENT_VCONN_READ_READY,
> sm=0x2b90b68a5d90, edata=0x2b907bb63d10) at SpdyClientSession.cc:381
> #3 0x0061af63 in SpdyClientSession::state_session_readwrite
> (this=0x2b90b68a5d90, event=100, edata=0x2b907bb63d10) at
> SpdyClientSession.cc:284
> #4 0x004f460e in Continuation::handleEvent (this=0x2b90b68a5d90,
> event=100, data=0x2b907bb63d10) at ../iocore/eventsystem/I_Continuation.h:146
> #5 0x004f28b0 in FetchSM::InvokePluginExt (this=0x2b907bb63d10,
> error_event=100) at FetchSM.cc:239
> #6 0x004f3620 in FetchSM::fetch_handler (this=0x2b907bb63d10,
> event=100, edata=0x2b90c23d8d48) at FetchSM.cc:479
> #7 0x004f460e in Continuation::handleEvent (this=0x2b907bb63d10,
> event=100, data=0x2b90c23d8d48) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0053054d in PluginVC::process_read_side (this=0x2b90c23d8c50,
> other_side_call=true) at PluginVC.cc:671
> #9 0x0052fde2 in PluginVC::process_write_side (this=0x2b90c23d8e30,
> other_side_call=false) at PluginVC.cc:567
> #10 0x0052eb84 in PluginVC::main_handler (this=0x2b90c23d8e30,
> event=1,
> data=0x2b90a2a6da00) at PluginVC.cc:212
> #11 0x004f460e in Continuation::handleEvent (this=0x2b90c23d8e30,
> event=1, data=0x2b90a2a6da00) at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x00751dca in EThread::process_event (this=0x2b8fa5646010,
> e=0x2b90a2a6da00, calling_code=1) at UnixEThread.cc:145
> #13 0x00751f98 in EThread::execute (this=0x2b8fa5646010) at
> UnixEThread.cc:196
> #14 0x00751328 in spawn_thread_internal (a=0x262c020) at Thread.cc:88
> #15 0x2b8f08129851 in start_thread () from /lib64/libpthread.so.0
> #16 0x003d158e890d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT
[ https://issues.apache.org/jira/browse/TS-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109363#comment-14109363 ] Leif Hedstrom commented on TS-3036: --- I suspect we'll need some more thinking / planning around this, in conjunction with the other cache changes required to properly support various media and how objects migrate between such layers. > Add logging field to define the cache medium used to serve a HIT > > > Key: TS-3036 > URL: https://issues.apache.org/jira/browse/TS-3036 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Ryan Frantz > Fix For: sometime > > > I want to be able to differentiate between RAM cache HITs and disk cache > HITs. Add a logging field to inform the administrator if the HIT came from > RAM, at least. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3035) Double logging on errored transactions
[
https://issues.apache.org/jira/browse/TS-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3035:
--
Fix Version/s: 5.2.0
> Double logging on errored transactions
> --
>
> Key: TS-3035
> URL: https://issues.apache.org/jira/browse/TS-3035
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.0
>
> Attachments: TS-3035.diff
>
>
> When an error occurs it results in transactions being logged twice, an
> example is:
> {code}
> 1408720751.393 0 72.52.91.30 ERR_CONNECT_FAIL 404 0 Accept-Language:
> https://en-US,en;q=0.8/ - NONE/- - https://en-US,en;q=0.8/ f1 f2 f3 f4
> 1408720751.393 0 72.52.91.30 ERR_CONNECT_FAIL 404 1820 Accept-Language:
> https://en-US,en;q=0.8/ - NONE/- text/html https://en-US,en;q=0.8/ f1 f2 f3 f4
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3028) Some ET_NET threads go to uninterruptable sleep with empty disk I/O
[ https://issues.apache.org/jira/browse/TS-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109367#comment-14109367 ] Leif Hedstrom commented on TS-3028: --- There's not a whole lot of details here. Have you tested this with our latest versions? 5.0.x? Also, v3.2.x is an unsupported version, so no future work will be done on this release. > Some ET_NET threads go to uninterruptable sleep with empty disk I/O > --- > > Key: TS-3028 > URL: https://issues.apache.org/jira/browse/TS-3028 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Jungwoo Lee > Attachments: disk_state.png, process_state.png > > > I use ATS 3.2.4 as a cache server. > Cached contents are a lot of small size files, image, html, xml and etc.. > Sometimes ET_NET threads go to uninterruptable sleep and no disk I/O occurs. > I attach pictures showing the status of threads( by shell command top ) and > those of disk( by shell command iostat 1 ) > And ATS system uses 2TB disk as a cache and 16GB memory. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3021) hosting.config vs volume.config
[ https://issues.apache.org/jira/browse/TS-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3021: -- Fix Version/s: sometime > hosting.config vs volume.config > --- > > Key: TS-3021 > URL: https://issues.apache.org/jira/browse/TS-3021 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Igor Galić > Fix For: sometime > > > it appears to me that hosting.config and volume.config have a very similar > purpose / use-case. perhaps it would be good to merge those two. > --- > n.b.: i'm not up-to-date on the plans re lua-config, but even then we'll need > to consider how to present. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3024) build with OPENSSL_NO_SSL_INTERN
[
https://issues.apache.org/jira/browse/TS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3024:
--
Fix Version/s: 5.2.0
> build with OPENSSL_NO_SSL_INTERN
>
>
> Key: TS-3024
> URL: https://issues.apache.org/jira/browse/TS-3024
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
>
> I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
> robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2285) Embed LUA with bindings to configuration points
[ https://issues.apache.org/jira/browse/TS-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2285: - Assignee: Leif Hedstrom (was: Theo Schlossnagle) > Embed LUA with bindings to configuration points > --- > > Key: TS-2285 > URL: https://issues.apache.org/jira/browse/TS-2285 > Project: Traffic Server > Issue Type: Sub-task >Reporter: Phil Sorber >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > We want to allow ATS to be configured by a LUA script. This requires > embedding LUA and exposing config points to it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3021) hosting.config vs volume.config
[ https://issues.apache.org/jira/browse/TS-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109369#comment-14109369 ] Leif Hedstrom commented on TS-3021: --- I think *IF* we're going to merge these, we should do it in a way that uses Lua. > hosting.config vs volume.config > --- > > Key: TS-3021 > URL: https://issues.apache.org/jira/browse/TS-3021 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Igor Galić > Fix For: sometime > > > it appears to me that hosting.config and volume.config have a very similar > purpose / use-case. perhaps it would be good to merge those two. > --- > n.b.: i'm not up-to-date on the plans re lua-config, but even then we'll need > to consider how to present. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3020) Blind Tunnel fake request URL is IPv4 only
[
https://issues.apache.org/jira/browse/TS-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3020:
--
Fix Version/s: 5.2.0
> Blind Tunnel fake request URL is IPv4 only
> --
>
> Key: TS-3020
> URL: https://issues.apache.org/jira/browse/TS-3020
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.5
>Reporter: Patrick McGleenon
>Priority: Minor
> Fix For: 5.2.0
>
>
> HttpTransact::HandleBlindTunnel creates a fake request with HTTP version 0.9
> and CONNECT method. The URL for CONNECT used is created from destination IP
> and port - currently this is IPv4 only.
> requests with IPv6 destination IP addresses still work fine with the
> BlindTunnel since ATS is able to figure out the correct IPv6 destination from
> the Host Header of the fake URL. So this is a problem just in the ATS
> logging
> attached is a suggested patch for 3.2 - the latest version of the file hasn't
> changed much since then
> {code}
> --- trafficserver-3.2.0/proxy/http/HttpTransact.cc2014-08-15
> 16:05:40.625721000 +0100
> +++ trafficserver-3.2.0.patched/proxy/http/HttpTransact.cc2014-08-15
> 16:58:23.563658000 +0100
> @@ -615,11 +615,12 @@
>HTTPVersion ver(0, 9);
>s->hdr_info.client_request.version_set(ver);
>
> - struct in_addr dest_addr;
> - dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> -
> - char *new_host = inet_ntoa(dest_addr);
> + // struct in_addr dest_addr;
>
> + // dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> + char new_host[INET6_ADDRSTRLEN];
> + ats_ip_ntop(s->state_machine->ua_session->get_netvc()->get_local_addr(),
> new_host, sizeof(new_host));
>s->hdr_info.client_request.url_get()->host_set(new_host, strlen(new_host));
> +
>// get_local_port() returns a port number in network order
> //opwv- FastPath
>// so it needs to be converted to host order (eg, in i386 machine)
> //opwv- FastPath
>
> //s->hdr_info.client_request.url_get()->port_set(ntohs(s->state_machine->ua_session->get_netvc()->get_local_port()));
> //opwv- FastPath
> {code}
> With patch:
> IPv4:
> Aug 18 09:49:24 - INFO - + Proxy's Request +
> Aug 18 09:49:24 - INFO - -- State Machine Id: 2
> Aug 18 09:49:24 - INFO - CONNECT 10.20.51.53:443 HTTP/1.1^M
> Aug 18 09:49:24 - INFO - Host: 10.20.51.53^M
> Aug 18 09:49:24 - INFO - Connection: close^M
> Aug 18 09:49:24 - INFO - ^M
> IPv6:
> Aug 18 09:47:18 - INFO - + Proxy's Request +
> Aug 18 09:47:18 - INFO - -- State Machine Id: 0
> Aug 18 09:47:18 - INFO - CONNECT [2001:410:0:51:20d:60ff:fe9c:eec4]:443
> HTTP/1.1^M
> Aug 18 09:47:18 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 18 09:47:18 - INFO - Connection: close^M
> Aug 18 09:47:18 - INFO - ^M
> without patch:
> Aug 13 14:44:45 - INFO - + Proxy's Request +
> Aug 13 14:44:45 - INFO - -- State Machine Id: 17
> Aug 13 14:44:45 - INFO - CONNECT 0.0.0.0:443 HTTP/1.1^M
> Aug 13 14:44:45 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 13 14:44:45 - INFO - Connection: close^M
> Aug 13 14:44:45 - INFO - ^M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-3020) Blind Tunnel fake request URL is IPv4 only
[
https://issues.apache.org/jira/browse/TS-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-3020:
-
Assignee: Leif Hedstrom
> Blind Tunnel fake request URL is IPv4 only
> --
>
> Key: TS-3020
> URL: https://issues.apache.org/jira/browse/TS-3020
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.5
>Reporter: Patrick McGleenon
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 5.2.0
>
>
> HttpTransact::HandleBlindTunnel creates a fake request with HTTP version 0.9
> and CONNECT method. The URL for CONNECT used is created from destination IP
> and port - currently this is IPv4 only.
> requests with IPv6 destination IP addresses still work fine with the
> BlindTunnel since ATS is able to figure out the correct IPv6 destination from
> the Host Header of the fake URL. So this is a problem just in the ATS
> logging
> attached is a suggested patch for 3.2 - the latest version of the file hasn't
> changed much since then
> {code}
> --- trafficserver-3.2.0/proxy/http/HttpTransact.cc2014-08-15
> 16:05:40.625721000 +0100
> +++ trafficserver-3.2.0.patched/proxy/http/HttpTransact.cc2014-08-15
> 16:58:23.563658000 +0100
> @@ -615,11 +615,12 @@
>HTTPVersion ver(0, 9);
>s->hdr_info.client_request.version_set(ver);
>
> - struct in_addr dest_addr;
> - dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> -
> - char *new_host = inet_ntoa(dest_addr);
> + // struct in_addr dest_addr;
>
> + // dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> + char new_host[INET6_ADDRSTRLEN];
> + ats_ip_ntop(s->state_machine->ua_session->get_netvc()->get_local_addr(),
> new_host, sizeof(new_host));
>s->hdr_info.client_request.url_get()->host_set(new_host, strlen(new_host));
> +
>// get_local_port() returns a port number in network order
> //opwv- FastPath
>// so it needs to be converted to host order (eg, in i386 machine)
> //opwv- FastPath
>
> //s->hdr_info.client_request.url_get()->port_set(ntohs(s->state_machine->ua_session->get_netvc()->get_local_port()));
> //opwv- FastPath
> {code}
> With patch:
> IPv4:
> Aug 18 09:49:24 - INFO - + Proxy's Request +
> Aug 18 09:49:24 - INFO - -- State Machine Id: 2
> Aug 18 09:49:24 - INFO - CONNECT 10.20.51.53:443 HTTP/1.1^M
> Aug 18 09:49:24 - INFO - Host: 10.20.51.53^M
> Aug 18 09:49:24 - INFO - Connection: close^M
> Aug 18 09:49:24 - INFO - ^M
> IPv6:
> Aug 18 09:47:18 - INFO - + Proxy's Request +
> Aug 18 09:47:18 - INFO - -- State Machine Id: 0
> Aug 18 09:47:18 - INFO - CONNECT [2001:410:0:51:20d:60ff:fe9c:eec4]:443
> HTTP/1.1^M
> Aug 18 09:47:18 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 18 09:47:18 - INFO - Connection: close^M
> Aug 18 09:47:18 - INFO - ^M
> without patch:
> Aug 13 14:44:45 - INFO - + Proxy's Request +
> Aug 13 14:44:45 - INFO - -- State Machine Id: 17
> Aug 13 14:44:45 - INFO - CONNECT 0.0.0.0:443 HTTP/1.1^M
> Aug 13 14:44:45 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 13 14:44:45 - INFO - Connection: close^M
> Aug 13 14:44:45 - INFO - ^M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3020) Blind Tunnel fake request URL is IPv4 only
[
https://issues.apache.org/jira/browse/TS-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109372#comment-14109372
]
Leif Hedstrom commented on TS-3020:
---
Would you be able to make and propose a patch against current master? v3.2.x is
an unsupported version, no future releases nor development is done for this
release.
> Blind Tunnel fake request URL is IPv4 only
> --
>
> Key: TS-3020
> URL: https://issues.apache.org/jira/browse/TS-3020
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.2.5
>Reporter: Patrick McGleenon
>Priority: Minor
> Fix For: 5.2.0
>
>
> HttpTransact::HandleBlindTunnel creates a fake request with HTTP version 0.9
> and CONNECT method. The URL for CONNECT used is created from destination IP
> and port - currently this is IPv4 only.
> requests with IPv6 destination IP addresses still work fine with the
> BlindTunnel since ATS is able to figure out the correct IPv6 destination from
> the Host Header of the fake URL. So this is a problem just in the ATS
> logging
> attached is a suggested patch for 3.2 - the latest version of the file hasn't
> changed much since then
> {code}
> --- trafficserver-3.2.0/proxy/http/HttpTransact.cc2014-08-15
> 16:05:40.625721000 +0100
> +++ trafficserver-3.2.0.patched/proxy/http/HttpTransact.cc2014-08-15
> 16:58:23.563658000 +0100
> @@ -615,11 +615,12 @@
>HTTPVersion ver(0, 9);
>s->hdr_info.client_request.version_set(ver);
>
> - struct in_addr dest_addr;
> - dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> -
> - char *new_host = inet_ntoa(dest_addr);
> + // struct in_addr dest_addr;
>
> + // dest_addr.s_addr =
> s->state_machine->ua_session->get_netvc()->get_local_ip();
> + char new_host[INET6_ADDRSTRLEN];
> + ats_ip_ntop(s->state_machine->ua_session->get_netvc()->get_local_addr(),
> new_host, sizeof(new_host));
>s->hdr_info.client_request.url_get()->host_set(new_host, strlen(new_host));
> +
>// get_local_port() returns a port number in network order
> //opwv- FastPath
>// so it needs to be converted to host order (eg, in i386 machine)
> //opwv- FastPath
>
> //s->hdr_info.client_request.url_get()->port_set(ntohs(s->state_machine->ua_session->get_netvc()->get_local_port()));
> //opwv- FastPath
> {code}
> With patch:
> IPv4:
> Aug 18 09:49:24 - INFO - + Proxy's Request +
> Aug 18 09:49:24 - INFO - -- State Machine Id: 2
> Aug 18 09:49:24 - INFO - CONNECT 10.20.51.53:443 HTTP/1.1^M
> Aug 18 09:49:24 - INFO - Host: 10.20.51.53^M
> Aug 18 09:49:24 - INFO - Connection: close^M
> Aug 18 09:49:24 - INFO - ^M
> IPv6:
> Aug 18 09:47:18 - INFO - + Proxy's Request +
> Aug 18 09:47:18 - INFO - -- State Machine Id: 0
> Aug 18 09:47:18 - INFO - CONNECT [2001:410:0:51:20d:60ff:fe9c:eec4]:443
> HTTP/1.1^M
> Aug 18 09:47:18 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 18 09:47:18 - INFO - Connection: close^M
> Aug 18 09:47:18 - INFO - ^M
> without patch:
> Aug 13 14:44:45 - INFO - + Proxy's Request +
> Aug 13 14:44:45 - INFO - -- State Machine Id: 17
> Aug 13 14:44:45 - INFO - CONNECT 0.0.0.0:443 HTTP/1.1^M
> Aug 13 14:44:45 - INFO - Host: 2001:410:0:51:20d:60ff:fe9c:eec4^M
> Aug 13 14:44:45 - INFO - Connection: close^M
> Aug 13 14:44:45 - INFO - ^M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3006: -- Fix Version/s: 5.2.0 > Augment SNI callback processing > --- > > Key: TS-3006 > URL: https://issues.apache.org/jira/browse/TS-3006 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: openssl-sni.patch > > > When starting to proxy a SSL connection, it would be nice to have the > servername available for decision making. The SNI callback gives us this > information. The SNI callback is currently used by core. Plugins may also > want to execute their own logic at the SNI callback. They can do that now > using the openssl calls directly, but that would remove the core SNI callback > processing. > We should add plugin calls to register code to be executed in the SNI > callback for a connection. The plugin code would be executed after the core > SNI callback logic. > In addition, there are scenarios when it would be useful to change how things > are processed after learning the server name, e.g., decide to blind tunnel > instead of proxy tunnel (see TS-2956) or perform some different certificate > calculations. Performing these extended operations are not feasible within > the SNI callback. Instead we want to break out of the SSL_accept() and > perform some other logic. > Openssl as it stands does not allow to break out of the openssl handshake > from the SNI callback short of issuing an error (which would send an error > message back to the client). We have created a patch that adds a new return > which breaks out of the SSL_accept() with a non-error but non-complete return > (like needs to read). If that patch was present, the core logic could be > extended to adjust processing. > In the blind tunnel case, the core logic could resend the first message > (client hello) directly to the original server and move into the blind tunnel > processing for the connection. In a certificate case, the core logic or some > plugin logic could perform some certificate calculations and then try the > SSL_accept() again at some later point in time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3008) make check fails for sslheaders when linked against libressl
[
https://issues.apache.org/jira/browse/TS-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3008:
--
Fix Version/s: sometime
> make check fails for sslheaders when linked against libressl
>
>
> Key: TS-3008
> URL: https://issues.apache.org/jira/browse/TS-3008
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins, SSL
>Reporter: Igor Galić
> Fix For: sometime
>
>
> {code}
> igalic@levix ...server/plugins/experimental/sslheaders (git)-[master] % make
> check V=1
> make test_sslheaders
> make[1]: Entering directory
> `/home/igalic/src/asf/trafficserver/plugins/experimental/sslheaders'
> /bin/bash ../../../libtool --tag=CXX --mode=link c++ -Wunused-parameter
> -std=c++11 -ggdb3 -pipe -Wall -Wno-invalid-offsetof -mcx16
> -L/opt/libressl/lib -o test_sslheaders test_sslheaders.o libsslhdr.la
> ../../../lib/ts/libtsutil.la -lcap -lpcre -lz -lcrypt -lpthread -ldl -lxml2
> libtool: link: c++ -Wunused-parameter -std=c++11 -ggdb3 -pipe -Wall
> -Wno-invalid-offsetof -mcx16 -o .libs/test_sslheaders test_sslheaders.o
> -L/opt/libressl/lib ./.libs/libsslhdr.a ../../../lib/ts/.libs/libtsutil.so
> -lcap -lpcre -lz -lcrypt -lpthread -ldl -lxml2 -Wl,-rpath
> -Wl,/opt/ats-trunk/lib
> /usr/bin/ld: test_sslheaders.o: undefined reference to symbol
> 'SSL_library_init'
> //opt/libressl/lib/libssl.so.27: error adding symbols: DSO missing from
> command line
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[1]: *** [test_sslheaders] Error 1
> make[1]: Leaving directory
> `/home/igalic/src/asf/trafficserver/plugins/experimental/sslheaders'
> make: *** [check-am] Error 2
> 2 igalic@levix ...server/plugins/experimental/sslheaders (git)-[master] %
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2895) memory allocation failure
[ https://issues.apache.org/jira/browse/TS-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2895: -- Fix Version/s: sometime > memory allocation failure > - > > Key: TS-2895 > URL: https://issues.apache.org/jira/browse/TS-2895 > Project: Traffic Server > Issue Type: Test > Components: Cache, Clustering >Reporter: wangjun >Assignee: Zhao Yongming > Labels: crash > Fix For: sometime > > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > In this version(ats 4.0.2), I encountered a bug (memory allocation failure), > Look at the system log, screenshots below(screenshot-1.jpg). > Look at the program logs, screenshots below((screenshot-2.jpg). > Please help me, thank you. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (TS-2949) apache traffic server crashes and restarts with the following Fatal error
[ https://issues.apache.org/jira/browse/TS-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom closed TS-2949. - Resolution: Duplicate Marking this as a dupe. > apache traffic server crashes and restarts with the following Fatal error > - > > Key: TS-2949 > URL: https://issues.apache.org/jira/browse/TS-2949 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Configuration >Reporter: saint > Labels: crash > > ATS 4.2.1 restarts with the following error. Please review and advise the > fix for this issue. > Jul 21 15:12:48 ats1 traffic_server[1863]: FATAL: ats_memalign: couldn't > allocate 666771456 bytes at alignment 4096 - insufficient memory > Jul 21 15:12:51 ats1 abrt[37147]: Can't open 'core.1863': Permission denied > Jul 21 15:15:49 ats1 kernel: INFO: task [ET_NET 0]:1863 blocked for more than > 120 seconds. > Jul 21 15:15:49 ats1 kernel: Not tainted 2.6.32-431.5.1.el6.x86_64 #1 > Jul 21 15:15:49 ats1 kernel: "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Jul 21 15:15:49 ats1 kernel: [ET_NET 0]D 0001 0 1863 > 1853 0x > Jul 21 15:15:49 ats1 kernel: 880c291a1c98 0086 > 880c291a1c60 880c291a1c5c > Jul 21 15:15:49 ats1 kernel: 880c291a1c68 880c3fe70a00 > 880053816840 2ff6 > Jul 21 15:15:49 ats1 kernel: 880c2bd33ab8 880c291a1fd8 > fbc8 880c2bd33ab8 > Jul 21 15:15:49 ats1 kernel: Call Trace: > Jul 21 15:15:49 ats1 kernel: [] exit_mm+0x95/0x180 > Jul 21 15:15:49 ats1 kernel: [] do_exit+0x15f/0x870 > Jul 21 15:15:49 ats1 kernel: [] ? thread_return+0x4e/0x76e > Jul 21 15:15:49 ats1 kernel: [] ? > lock_hrtimer_base+0x31/0x60 > Jul 21 15:15:49 ats1 kernel: [] do_group_exit+0x58/0xd0 > Jul 21 15:15:49 ats1 kernel: [] > get_signal_to_deliver+0x1f6/0x460 > Jul 21 15:15:49 ats1 kernel: [] do_signal+0x75/0x800 > Jul 21 15:15:49 ats1 kernel: [] ? ep_poll+0x306/0x330 > Jul 21 15:15:49 ats1 kernel: [] ? > default_wake_function+0x0/0x20 > Jul 21 15:15:49 ats1 kernel: [] do_notify_resume+0x90/0xc0 > Jul 21 15:15:49 ats1 kernel: [] int_signal+0x12/0x17 > Jul 21 15:15:49 ats1 kernel: INFO: task traffic_server:1864 blocked for more > than 120 seconds. > Jul 21 15:15:49 ats1 kernel: Not tainted 2.6.32-431.5.1.el6.x86_64 #1 > Jul 21 15:15:49 ats1 kernel: "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Jul 21 15:15:49 ats1 kernel: traffic_serve D 0002 0 1864 > 1853 0x > Jul 21 15:15:49 ats1 kernel: 880c2ab29c98 0086 > 880c2d8cec00 000492d0811364bc > Jul 21 15:15:49 ats1 kernel: 880c2ab29c68 810af360 > 0001 0286 > Jul 21 15:15:49 ats1 kernel: 88095292a638 880c2ab29fd8 > fbc8 88095292a638 > Jul 21 15:15:49 ats1 kernel: Call Trace: > Jul 21 15:15:49 ats1 kernel: [] ? > exit_robust_list+0x90/0x160 > Jul 21 15:15:49 ats1 kernel: [] exit_mm+0x95/0x180 > Jul 21 15:15:49 ats1 kernel: [] do_exit+0x15f/0x870 > Jul 21 15:15:49 ats1 kernel: [] ? dequeue_entity+0x113/0x2e0 > Jul 21 15:15:49 ats1 kernel: [] ? __dequeue_entity+0x30/0x50 > Jul 21 15:15:49 ats1 kernel: [] do_group_exit+0x58/0xd0 > Jul 21 15:15:49 ats1 kernel: [] > get_signal_to_deliver+0x1f6/0x460 > Jul 21 15:15:49 ats1 kernel: [] do_signal+0x75/0x800 > Jul 21 15:15:49 ats1 kernel: [] ? > hrtimer_nanosleep+0xe7/0x180 > Jul 21 15:15:49 ats1 kernel: [] ? hrtimer_wakeup+0x0/0x30 > Jul 21 15:15:49 ats1 kernel: [] do_notify_resume+0x90/0xc0 > Jul 21 15:15:49 ats1 kernel: [] int_signal+0x12/0x17 > Jul 21 15:15:49 ats1 kernel: INFO: task [ET_NET 1]:1865 blocked for more than > 120 seconds. > Jul 21 15:15:49 ats1 kernel: Not tainted 2.6.32-431.5.1.el6.x86_64 #1 > Jul 21 15:15:49 ats1 kernel: "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Jul 21 15:15:49 ats1 kernel: [ET_NET 1]D 0003 0 1865 > 1853 0x > Jul 21 15:15:49 ats1 kernel: 8806f1bcfc98 0086 > 0b6881179941 > Jul 21 15:15:49 ats1 kernel: 8806f1bcfc68 810af360 > 8806f1bcfe58 8806f1bcfd08 > Jul 21 15:15:49 ats1 kernel: 880c288b9af8 8806f1bcffd8 > fbc8 880c288b9af8 > Jul 21 15:15:49 ats1 kernel: Call Trace: > Jul 21 15:15:49 ats1 kernel: [] ? > exit_robust_list+0x90/0x160 > Jul 21 15:15:49 ats1 kernel: [] exit_mm+0x95/0x180 > Jul 21 15:15:49 ats1 kernel: [] do_exit+0x15f/0x870 > Jul 21 15:15:49 ats1 kernel: [] ? sock_aio_write+0x0/0x1c0 > Jul 21 15:15:49 ats1 kernel: [] ? > do_sync_readv_writev+0xfb/0x140 > Jul 21 15:15:49 ats1 kernel: [] do_group_exit+0x58/0xd0 > Jul 21 15:15:49 ats1 kernel: [] > get_signal_to_deliver+0x1f6/0x460 > Jul 2
[jira] [Updated] (TS-2895) memory allocation failure
[ https://issues.apache.org/jira/browse/TS-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2895: -- Fix Version/s: (was: sometime) > memory allocation failure > - > > Key: TS-2895 > URL: https://issues.apache.org/jira/browse/TS-2895 > Project: Traffic Server > Issue Type: Test > Components: Cache, Clustering >Reporter: wangjun >Assignee: Zhao Yongming > Labels: crash > Fix For: sometime > > Attachments: screenshot-1.jpg, screenshot-2.jpg > > > In this version(ats 4.0.2), I encountered a bug (memory allocation failure), > Look at the system log, screenshots below(screenshot-1.jpg). > Look at the program logs, screenshots below((screenshot-2.jpg). > Please help me, thank you. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT
[ https://issues.apache.org/jira/browse/TS-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109379#comment-14109379 ] Ryan Frantz commented on TS-3036: - Interestingly enough, after compiling a version with this patch and running tests, I found that log entries with a cache result (crc) of MEM_HIT were showing up in my logs. I dug into the commit history and found this: https://github.com/apache/trafficserver/commit/2042a1731de0726186ffa9e878dfcd027c537604#diff-d41d8cd98f00b204e9800998ecf8427e The work was done for the following ticket: https://issues.apache.org/jira/browse/TS-2944 My patch is probably moot at this point. > Add logging field to define the cache medium used to serve a HIT > > > Key: TS-3036 > URL: https://issues.apache.org/jira/browse/TS-3036 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Ryan Frantz > Fix For: sometime > > > I want to be able to differentiate between RAM cache HITs and disk cache > HITs. Add a logging field to inform the administrator if the HIT came from > RAM, at least. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3041) add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3041:
Fix Version/s: 5.2.0
Assignee: James Peach
> add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-3041) add a way to show the installation layout
James Peach created TS-3041:
---
Summary: add a way to show the installation layout
Key: TS-3041
URL: https://issues.apache.org/jira/browse/TS-3041
Project: Traffic Server
Issue Type: New Feature
Components: Configuration, Core
Reporter: James Peach
Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
installation. Nuke the really annoying code that dumps the layout to stdout
when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-3042) fix the static traffic_server build
James Peach created TS-3042:
---
Summary: fix the static traffic_server build
Key: TS-3042
URL: https://issues.apache.org/jira/browse/TS-3042
Project: Traffic Server
Issue Type: Bug
Components: Build, Core
Reporter: James Peach
Restore the ability to link {{traffic_server}} statically, while linking the
rest of the project dynamically.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3034) unanchored traffic_line metrics match
[
https://issues.apache.org/jira/browse/TS-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109919#comment-14109919
]
ASF subversion and git services commented on TS-3034:
-
Commit 70eee230a68d3e6996b7a9911cee5b07e0a60b59 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70eee23 ]
TS-3034: add unanchored regex option
Add unanchored regex option and use it for traffic_line -m so that
filtering record names is easier.
> unanchored traffic_line metrics match
> -
>
> Key: TS-3034
> URL: https://issues.apache.org/jira/browse/TS-3034
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Tools
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> The regex passed to {{traffic_line -m}} is anchored, which makes is pretty
> annoying to match record names. We should do an unanchored match to make it
> easier to find names.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3033) reimplement management protocol
[ https://issues.apache.org/jira/browse/TS-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109917#comment-14109917 ] ASF subversion and git services commented on TS-3033: - Commit 3b5694136c2529516554dbdee3cfcb8944ba83f9 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3b56941 ] TS-3033: generic message initial marshalling Implement a very simple generic message marshalling API. This is similar to the existing hand-rolled marshalling, except that there are fewer data types, and it is all implemented in a single place. Add MgmtSocket.cc because there's really no benefit to having all the mgmt socket wrappers inline. Move some more helper API over to MgmtSocket. > reimplement management protocol > --- > > Key: TS-3033 > URL: https://issues.apache.org/jira/browse/TS-3033 > Project: Traffic Server > Issue Type: Bug > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > The management protocol is hand-crafted for each message type. That's a lot > of code and it makes it unnecessarily complicated to add new message types. > Let's introduce a simple, generic marshaling format and use that everywhere. > The format I have implemented can be used for signaling traffic_server as > well, but for now this is just changing API messages to traffic_manager. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3042) fix the static traffic_server build
[
https://issues.apache.org/jira/browse/TS-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109921#comment-14109921
]
ASF subversion and git services commented on TS-3042:
-
Commit 60d2106eddc841882a9a111b008ed67bd0953f41 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=60d2106 ]
TS-3042: fix the static traffic_server build
Rename --enable-static-libts to --enable-static-proxy, since that's
a better description of what it does. Use this option to default
the libtool static library options so that it works correctly.
> fix the static traffic_server build
> ---
>
> Key: TS-3042
> URL: https://issues.apache.org/jira/browse/TS-3042
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Core
>Reporter: James Peach
>
> Restore the ability to link {{traffic_server}} statically, while linking the
> rest of the project dynamically.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3033) reimplement management protocol
[ https://issues.apache.org/jira/browse/TS-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109918#comment-14109918 ] ASF subversion and git services commented on TS-3033: - Commit 6250f431bb6c0d61b55aa21bd7a00b7d059a73a9 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6250f43 ] TS-3033: reimplement management API with generic marshalling This reimplements the management protocol on top of the generic message marshalling API. > reimplement management protocol > --- > > Key: TS-3033 > URL: https://issues.apache.org/jira/browse/TS-3033 > Project: Traffic Server > Issue Type: Bug > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > The management protocol is hand-crafted for each message type. That's a lot > of code and it makes it unnecessarily complicated to add new message types. > Let's introduce a simple, generic marshaling format and use that everywhere. > The format I have implemented can be used for signaling traffic_server as > well, but for now this is just changing API messages to traffic_manager. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3041) add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109920#comment-14109920
]
ASF subversion and git services commented on TS-3041:
-
Commit 02d9200979ed4932b10154c33c258e47445f0b78 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=02d9200 ]
TS-3041: traffic_layout tool
Add a simple traffic_layout tool to show the location of various
installation paths and resources.
> add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-3033) reimplement management protocol
[ https://issues.apache.org/jira/browse/TS-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-3033. - Resolution: Fixed > reimplement management protocol > --- > > Key: TS-3033 > URL: https://issues.apache.org/jira/browse/TS-3033 > Project: Traffic Server > Issue Type: Bug > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > The management protocol is hand-crafted for each message type. That's a lot > of code and it makes it unnecessarily complicated to add new message types. > Let's introduce a simple, generic marshaling format and use that everywhere. > The format I have implemented can be used for signaling traffic_server as > well, but for now this is just changing API messages to traffic_manager. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-3034) unanchored traffic_line metrics match
[
https://issues.apache.org/jira/browse/TS-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3034.
-
Resolution: Fixed
> unanchored traffic_line metrics match
> -
>
> Key: TS-3034
> URL: https://issues.apache.org/jira/browse/TS-3034
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Tools
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> The regex passed to {{traffic_line -m}} is anchored, which makes is pretty
> annoying to match record names. We should do an unanchored match to make it
> easier to find names.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3042) fix the static traffic_server build
[
https://issues.apache.org/jira/browse/TS-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3042:
Fix Version/s: 5.1.0
Assignee: James Peach
> fix the static traffic_server build
> ---
>
> Key: TS-3042
> URL: https://issues.apache.org/jira/browse/TS-3042
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> Restore the ability to link {{traffic_server}} statically, while linking the
> rest of the project dynamically.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-3041) add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3041.
-
Resolution: Fixed
> add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-3042) fix the static traffic_server build
[
https://issues.apache.org/jira/browse/TS-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3042.
-
Resolution: Fixed
> fix the static traffic_server build
> ---
>
> Key: TS-3042
> URL: https://issues.apache.org/jira/browse/TS-3042
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.1.0
>
>
> Restore the ability to link {{traffic_server}} statically, while linking the
> rest of the project dynamically.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3042) fix the static traffic_server build
[
https://issues.apache.org/jira/browse/TS-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3042:
Fix Version/s: (was: 5.1.0)
5.2.0
> fix the static traffic_server build
> ---
>
> Key: TS-3042
> URL: https://issues.apache.org/jira/browse/TS-3042
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Restore the ability to link {{traffic_server}} statically, while linking the
> rest of the project dynamically.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-3043) auth_proxy plugin doc doesn't talk about auth remap rule required
Miles Libbey created TS-3043: Summary: auth_proxy plugin doc doesn't talk about auth remap rule required Key: TS-3043 URL: https://issues.apache.org/jira/browse/TS-3043 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Miles Libbey When using the authproxy plugin, one must configure a remap rule to handle the request that goes to the authorization server. The current docs don't mention this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3043) auth_proxy plugin doc doesn't talk about auth remap rule required
[ https://issues.apache.org/jira/browse/TS-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109977#comment-14109977 ] Miles Libbey commented on TS-3043: -- diff --git a/doc/reference/plugins/authproxy.en.rst b/doc/reference/plugins/authproxy.en.rst index e2241a1..c30f185 100644 --- a/doc/reference/plugins/authproxy.en.rst +++ b/doc/reference/plugins/authproxy.en.rst @@ -35,6 +35,12 @@ plugin. you can disable this behavior by setting :ts:cv:`proxy.config.http.doc_in_cache_skip_dns` to ``0`` in :file:`records.config`. +Traffic Server requires a remap rule for the authorization request. +As a result, the pristine Host header for the initial request will +not automatically be sent. The Host header could be added using the +``header_rewrite`` plugin (set-header Host "pristine_host.example.com"). + + Plugin Options -- @@ -84,8 +90,14 @@ HTTP request to a `HEAD` request and sending that to the origin server map http://cache.example.com http://origin.internal.com/ \ @plugin=authproxy.so @pparam=--auth-transform=head + map http://origin.internal.com http://origin.internal.com/ + + In this example, the request is directed to a local authentication server that authorizes the request based on internal policy rules:: map http://cache.example.com http://origin.internal.com/ \ @plugin=authproxy.so @pparam=--auth-transform=redirect @pparam=--auth-host=127.0.0.1 @pparam=--auth-port=9000 + + map http://origin.internal.com/ http://origin.internal.com/ \ +@plugin=authproxy.so @pparam=--auth-transform=redirect @pparam=--auth-host=127.0.0.1 @pparam=--auth-port=9000 > auth_proxy plugin doc doesn't talk about auth remap rule required > - > > Key: TS-3043 > URL: https://issues.apache.org/jira/browse/TS-3043 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Miles Libbey > > When using the authproxy plugin, one must configure a remap rule to handle > the request that goes to the authorization server. The current docs don't > mention this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-3044: - Assignee: weijin > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: weijin > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-3044) linux native AIO should use eventfd if available to signal thread
John Plevyak created TS-3044: Summary: linux native AIO should use eventfd if available to signal thread Key: TS-3044 URL: https://issues.apache.org/jira/browse/TS-3044 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: John Plevyak linux native AIO has the ability to signal the event thread to get off the poll and service the disk via the io_set_eventfd() call. linux native AIO scales better than the thread-based IO, but the current implementation can introduce delays on lightly loaded systems because of the thread is waiting on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-3044: - Attachment: native-aio-eventfd.patch > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: weijin > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110181#comment-14110181 ] John Plevyak commented on TS-3044: -- Assigned to weijin for review as he was in charge of the native linux AIO and can assess the impact. As I remember, this isn't enabled by default because of the latency concerns by Leif. With this patch, if the latency concerns are addressed, we might want to enable this feature by default. > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: weijin > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3044: -- Fix Version/s: 5.2.0 > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: weijin > Fix For: 5.2.0 > > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110206#comment-14110206 ] weijin commented on TS-3044: Nice work, John. And I can`t wait to test it. :) > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: weijin > Fix For: 5.2.0 > > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
