[jira] [Commented] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[ https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239294#comment-13239294 ] Conan Wang commented on TS-1114: get Hunk #1 FAILED at 1491 when try to backport, because TS-1084 also has a simple modify to the code. > Crash report: HttpTransactCache::SelectFromAlternates > - > > Key: TS-1114 > URL: https://issues.apache.org/jira/browse/TS-1114 > Project: Traffic Server > Issue Type: Bug >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 3.1.4 > > Attachments: cache_crash.diff > > > it may or may not be the upstream issue, let us open it for tracking. > {code} > #0 0x0053075e in HttpTransactCache::SelectFromAlternates > (cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0, > http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375 > 1375((int32_t *) & val)[0] = m_alt->m_object_key[0]; > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[ https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238281#comment-13238281 ] Conan Wang commented on TS-1002: I'm trying to backport to 3.0.4. got assert error when request. {code} FATAL: LogAccess.cc:794: failed assert `actual_len < padded_len` /box/ts-3.0.4/bin/traffic_server - STACK TRACE: 0 libtsutil.3.dylib 0x000100d2924b ink_fatal_va + 283 1 libtsutil.3.dylib 0x000100d29554 ink_fatal + 356 2 libtsutil.3.dylib 0x000100d268cf _ink_assert + 271 3 traffic_server 0x0001001b9c90 _ZN9LogAccess11marshal_memEPcPKcii + 108 4 traffic_server 0x0001001bd848 _ZN13LogAccessHttp36marshal_client_req_unmapped_url_hostEPc + 122 5 traffic_server 0x0001001e2d7b _ZN8LogField7marshalEP9LogAccessPc + 155 6 traffic_server 0x0001001e2f30 _ZN12LogFieldList7marshalEP9LogAccessPc + 88 7 traffic_server 0x0001001fb45b _ZN9LogObject3logEP9LogAccessPc + 3783 8 traffic_server 0x0001001cff91 _ZN16LogObjectManager3logEP9LogAccess + 73 9 traffic_server 0x0001001c5f48 _ZN3Log6accessEP9LogAccess + 1316 10 traffic_server 0x000100116bc4 _ZN6HttpSM12update_statsEv + 834 11 traffic_server 0x00010012944a _ZN6HttpSM9kill_thisEv + 1042 12 traffic_server 0x000100129aa7 _ZN6HttpSM12main_handlerEiPv + 1205 13 traffic_server 0x00010005cc84 _ZN12Continuation11handleEventEiPv + 148 14 traffic_server 0x000100184044 _ZN10HttpTunnel12main_handlerEiPv + 460 15 traffic_server 0x00010005cc84 _ZN12Continuation11handleEventEiPv + 148 16 traffic_server 0x00010036a2c4 _ZL23write_signal_and_updateiP18UnixNetVConnection + 100 17 traffic_server 0x00010036a3d2 _ZL17write_signal_doneiP10NetHandlerP18UnixNetVConnection + 50 18 traffic_server 0x00010036ae91 _Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread + 2593 19 traffic_server 0x00010036b0e8 _Z12write_to_netP10NetHandlerP18UnixNetVConnectionP14PollDescriptorP7EThread + 168 20 traffic_server 0x00010035cd34 _ZN10NetHandler12mainNetEventEiP5Event + 4346 21 traffic_server 0x00010005cc84 _ZN12Continuation11handleEventEiPv + 148 22 traffic_server 0x00010039145a _ZN7EThread13process_eventEP5Eventi + 418 23 traffic_server 0x000100390cab _ZN7EThread7executeEv + 1311 24 traffic_server 0x00010038fc74 _ZL21spawn_thread_internalPv + 132 25 libsystem_c.dylib 0x7fff89dfe8bf _pthread_start + 335 26 libsystem_c.dylib 0x7fff89e01b75 thread_start + 13 Program received signal SIGABRT, Aborted. [Switching to process 14628 thread 0x2803] 0x7fff90895ce2 in __pthread_kill () (gdb) bt #0 0x7fff90895ce2 in __pthread_kill () #1 0x7fff89e007d2 in pthread_kill () #2 0x7fff89df1a7a in abort () #3 0x000100d27f70 in ink_die_die_die (retval=1) at ink_error.cc:43 #4 0x000100d29255 in ink_fatal_va (return_code=1, message_format=0x103d0950c "LogAccess.cc:794: failed assert `actual_len < padded_len`", ap=0x103d09498) at ink_error.cc:65 #5 0x000100d29554 in ink_fatal (return_code=1, message_format=0x103d0950c "LogAccess.cc:794: failed assert `actual_len < padded_len`") at ink_error.cc:73 #6 0x000100d268cf in _ink_assert (a=0x1003e2532 "actual_len < padded_len", f=0x1003e23b8 "LogAccess.cc", l=794) at ink_assert.cc:44 #7 0x0001001b9c90 in LogAccess::marshal_mem (dest=0x108c4f910 "", source=0x1003e2530 "-", actual_len=1, padded_len=0) at LogAccess.cc:794 #8 0x0001001bd848 in LogAccessHttp::marshal_client_req_unmapped_url_host (this=0x103d0a328, buf=0x108c4f910 "") at LogAccessHttp.cc:369 #9 0x0001001e2d7b in LogField::marshal (this=0x10128c8e0, lad=0x103d0a328, buf=0x108c4f910 "") at LogField.cc:216 #10 0x0001001e2f30 in LogFieldList::marshal (this=0x10128be80, lad=0x103d0a328, buf=0x108c4f910 "") at LogField.cc:493 #11 0x0001001fb45b in LogObject::log (this=0x108c51e00, lad=0x103d0a328, text_entry=0x0) at LogObject.cc:568 #12 0x0001001cff91 in LogObjectManager::log (this=0x101247040, lad=0x103d0a328) at LogObject.h:485 #13 0x0001001c5f48 in Log::access (lad=0x103d0a328) at Log.cc:1063 #14 0x000100116bc4 in HttpSM::update_stats (this=0x109d41190) at HttpSM.cc:6044 #15 0x00010012944a in HttpSM::kill_this (this=0x109d41190) at HttpSM.cc:6005 #16 0x000100129aa7 in HttpSM::main_handler (this=0x109d41190, event=2301,
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[ https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225806#comment-13225806 ] Conan Wang commented on TS-1002: docs need mention that 'cquup' also logs querystring. > log unmapped HOST when pristine_host_hdr disabled > - > > Key: TS-1002 > URL: https://issues.apache.org/jira/browse/TS-1002 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Conan Wang >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.3 > > Attachments: TS-1002.patch > > > I want to log user request's "Host" in http header before remap. I write > logs_xml.config, like: %<{Host}cqh> > When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the > right "Host" which is not rewritten. > When disable the config, I always get the rewritten/mapped "Host" which is > not what I need. > logs_xml reference: > http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[ https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222176#comment-13222176 ] Conan Wang commented on TS-1002: btw, I didn't find a symbol which log url path with querystring before. like /trafficserver/ts75.png?version=1 And your "cquup" can do this now. Is this new symbol on trunk? > log unmapped HOST when pristine_host_hdr disabled > - > > Key: TS-1002 > URL: https://issues.apache.org/jira/browse/TS-1002 > Project: Traffic Server > Issue Type: Wish > Components: Logging >Reporter: Conan Wang >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.3 > > Attachments: TS-1002.patch > > > I want to log user request's "Host" in http header before remap. I write > logs_xml.config, like: %<{Host}cqh> > When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the > right "Host" which is not rewritten. > When disable the config, I always get the rewritten/mapped "Host" which is > not what I need. > logs_xml reference: > http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[ https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221538#comment-13221538 ] Conan Wang commented on TS-1002: % works, thanks! cdn.zymlinux.net - 0 TCP_MISS [03/Mar/2012:15:38:47 +0800] "GET /trafficserver/ts75.png HTTP/1.1" 200 9520 "-" "-" "curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5" > log unmapped HOST when pristine_host_hdr disabled > - > > Key: TS-1002 > URL: https://issues.apache.org/jira/browse/TS-1002 > Project: Traffic Server > Issue Type: Wish > Components: Logging >Reporter: Conan Wang >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.3 > > Attachments: TS-1002.patch > > > I want to log user request's "Host" in http header before remap. I write > logs_xml.config, like: %<{Host}cqh> > When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the > right "Host" which is not rewritten. > When disable the config, I always get the rewritten/mapped "Host" which is > not what I need. > logs_xml reference: > http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[ https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220704#comment-13220704 ] Conan Wang commented on TS-1002: not fix in my test. CONFIG proxy.config.url_remap.pristine_host_hdr INT 0 maphttp://cdn.zymlinux.nethttp://zymlinux.net squid.log 1330668375.573 119 127.0.0.1 TCP_MISS/200 9821 GET http://zymlinux.net/trafficserver/ts75.png - DIRECT/zymlinux.net image/png - custom.log ( first field is %<{Host}cqh> ) zymlinux.net - 0 TCP_MISS [02/Mar/2012:14:06:15 +0800] "GET /trafficserver/ts75.png HTTP/1.1" 200 9520 "-" "-" "curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5" > log unmapped HOST when pristine_host_hdr disabled > - > > Key: TS-1002 > URL: https://issues.apache.org/jira/browse/TS-1002 > Project: Traffic Server > Issue Type: Wish > Components: Logging >Reporter: Conan Wang >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.5 > > > I want to log user request's "Host" in http header before remap. I write > logs_xml.config, like: %<{Host}cqh> > When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the > right "Host" which is not rewritten. > When disable the config, I always get the rewritten/mapped "Host" which is > not what I need. > logs_xml reference: > http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1103) Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208216#comment-13208216 ] Conan Wang commented on TS-1103: agree that gzip module of ESI is invalid for chrome. > Traffic Server ESI plugin issues > > > Key: TS-1103 > URL: https://issues.apache.org/jira/browse/TS-1103 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: sometime > Environment: Newest trunk. >Reporter: Kevin Fox > Attachments: esi.patch > > > Patch to fix: > * Makefile fix to add missing files. > * Change return code checking to match whats trunk trafficserver. > * Include missing header files. > * Fix c++ namespace issues. > * Work around strange name mangling/linking issue. > * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI. > Things wouldn't work without it. > * Comment out a block of code that looked to be incorrectly handling > EOF. > After this, simply loading the plugin and setting response header X-ESI > in apache httpd seems to work. > A few further bugs I have bumped into that aren't addressed in this > patch: > * It doesn't seem to parse gzip like it looks like it should. To work > around, I had to disable it in apache httpd with "RewriteRule . - > [E=no-gzip:1]" > * If the client requests gzip, the ESI processor will gzip the result. > It works in firefox but is invalid in chrome. Pulling a dump with curl > and running it through gzip --list shows it has the correct uncompressed > size and compressed size. using zcat shows the correct data but has the > warning: "invalid compressed data--length error". As far as I read the > gzip spec though, the raw binary file looks valid to me. Not sure what > this is. This can probably be simply disabled for now though. > * esi:include is slightly broken. You get all the data back properly but > sometimes the headers are sent prematurely with a Content-Length of > 2**31-1. This causes clients to timeout and fail. I'm currently unsure > how to fix this. > I've tried a few of the more advanced esi features, including ensuring > cookies make it back to the origin server and things seem to work good. > So, once the above bugs are figured out (particularly the include one), > I think it will be in pretty good shape. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1100) Coredump at startup when there's a duplicate remap rule
[ https://issues.apache.org/jira/browse/TS-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197935#comment-13197935 ] Conan Wang commented on TS-1100: I think TS-948 has fixed this? https://issues.apache.org/jira/browse/TS-948 > Coredump at startup when there's a duplicate remap rule > --- > > Key: TS-1100 > URL: https://issues.apache.org/jira/browse/TS-1100 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.1 > Environment: Bog standard linux/x86; own build. >Reporter: Nick Kew >Priority: Minor > > A minor accident with cut&paste in vi leads to TS coredumping at startup. > I had duplicated a line in remap.config: > map http://myhost:8080/ http://target/ > () > map http://myhost:8080/ http://target/ > The second instance is line 125 in remap.config, and the dump shows: > FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 125 > bin/traffic_server - STACK TRACE: > /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0xe21873] > /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal+0x2b)[0xe218c5] > bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x1e48)[0x81e1120] > bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x562)[0x810] > bin/traffic_server(_Z18init_reverse_proxyv+0x41)[0x815500b] > bin/traffic_server(_Z20init_HttpProxyServerv+0xe)[0x818fccc] > bin/traffic_server(main+0xf7f)[0x813b65d] > /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x692bd6] > bin/traffic_server[0x80f6001] > Aborted -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1027) remap.config limited to ~255 entries
[ https://issues.apache.org/jira/browse/TS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162566#comment-13162566 ] Conan Wang commented on TS-1027: btw: Is there a limit? Will growing number of remap rule impact the performance? There are a lot of "map http://ban.com http://org.ban.com @action=deny" in my remap.config. > remap.config limited to ~255 entries > > > Key: TS-1027 > URL: https://issues.apache.org/jira/browse/TS-1027 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 3.0.2 >Reporter: Greg Dallavalle > > Remap.config errors out trafficserver when the entries exceed ~249 > Due to issue TS-1024 I am using a large number of remaps to workaround the > issue. With this limit I'm unable to proceed with ATS. If there are ways to > overcome these problems, by all means, I'd be happy to listen and test. > The errors from traffic.out: > [Nov 21 15:20:08.572] Server {1080866016} ERROR: Cannot insert duplicate! > [Nov 21 15:20:08.573] Server {1080866016} ERROR: Couldn't insert into trie! > [Nov 21 15:20:08.573] Server {1080866016} ERROR: Could not insert new mapping > [Nov 21 15:20:08.573] Server {1080866016} WARNING: Could not add rule at line > #249; Aborting! > [Nov 21 15:20:08.578] Server {1080866016} WARNING: [ReverseProxy] Unable to > add mapping rule to lookup table at line 249 > FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 249 > /usr/bin/traffic_server - STACK TRACE: > /usr/lib/trafficserver/libtsutil.so.3(ink_fatal_va+0xf7)[0x400301a7] > /usr/lib/trafficserver/libtsutil.so.3(ink_fatal+0x2c)[0x4003020c] > /usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x5a2)[0x819b402] > /usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x337)[0x819da87] > /usr/bin/traffic_server(_Z18init_reverse_proxyv+0x9a)[0x810bb6a] > /usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x814664b] > /usr/bin/traffic_server(main+0x12bb)[0x80b547b] > /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40561113] > /usr/bin/traffic_server[0x80baffd] > [Nov 21 15:20:08.638] Manager {3072087760} ERROR: > [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6: > Aborted > [Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No > such file or directory) > [Nov 21 15:20:08.639] Manager {3072087760} ERROR: [Alarms::signalAlarm] > Server Process was reset > [Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No > such file or directory) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[ https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139397#comment-13139397 ] Conan Wang commented on TS-1006: my reverse box: 3.0.1 on centos 5.4 64bit physics memory: 4G RAM cache: 1.8G DISK: 407 GB (raw device) average_object_size: 8000 {code} allocated |in-use | type size | free list name |||-- 67108864 | 0 |2097152 | memory/ioBufAllocator[14] 1744830464 | 76546048 |1048576 | memory/ioBufAllocator[13] 33554432 |4194304 | 524288 | memory/ioBufAllocator[12] 33554432 |6553600 | 262144 | memory/ioBufAllocator[11] 37748736 |8912896 | 131072 | memory/ioBufAllocator[10] 69206016 | 31850496 | 65536 | memory/ioBufAllocator[9] 529530880 | 365658112 | 32768 | memory/ioBufAllocator[8] 414187520 | 411942912 | 16384 | memory/ioBufAllocator[7] 898629632 | 898547712 | 8192 | memory/ioBufAllocator[6] 83361792 | 83161088 | 4096 | memory/ioBufAllocator[5] 262144 | 0 | 2048 | memory/ioBufAllocator[4] 131072 | 0 | 1024 | memory/ioBufAllocator[3] 65536 | 0 |512 | memory/ioBufAllocator[2] 32768 | 0 |256 | memory/ioBufAllocator[1] 0 | 0 |128 | memory/ioBufAllocator[0] 0 | 0 |576 | memory/ICPRequestCont_allocator 0 | 0 |112 | memory/ICPPeerReadContAllocator 0 | 0 |432 | memory/PeerReadDataAllocator 4096 |160 | 32 | memory/MIMEFieldSDKHandle 0 | 0 |240 | memory/INKVConnAllocator 12288 | 96 | 96 | memory/INKContAllocator 4096 | 32 | 32 | memory/apiHookAllocator 0 | 0 |288 | memory/FetchSMAllocator 0 | 0 | 80 | memory/prefetchLockHandlerAllocator 0 | 0 |176 | memory/PrefetchBlasterAllocator 0 | 0 | 80 | memory/prefetchUrlBlaster 0 | 0 | 96 | memory/blasterUrlList 0 | 0 | 96 | memory/prefetchUrlEntryAllocator 0 | 0 |128 | memory/socksProxyAllocator 0 | 0 |144 | memory/ObjectReloadCont 1060864 | 2960 |592 | memory/httpClientSessionAllocator 53248 |416 |208 | memory/httpServerSessionAllocator 17575936 | 19616 | 9808 | memory/httpSMAllocator 0 | 0 | 32 | memory/CacheLookupHttpConfigAllocator 0 | 0 | 9856 | memory/httpUpdateSMAllocator 0 | 0 |128 | memory/RemapPluginsAlloc 0 | 0 | 48 | memory/CongestRequestParamAllocator 0 | 0 |128 | memory/CongestionDBContAllocator 7340032 | 264192 | 2048 | memory/hdrStrHeap 8650752 | 274432 | 2048 | memory/hdrHeap # 26624 | 0 |208 | memory/httpCacheAltAllocator 0 | 0 |112 | memory/OneWayTunnelAllocator 315392 | 1232 | 1232 | memory/hostDBContAllocator 68160 | 17040 | 17040 | memory/dnsBufAllocator 161792 | 0 | 1264 | memory/dnsEntryAllocator 0 | 0 | 16 | memory/DNSRequestDataAllocator 0 | 0 | 1072 | memory/SRVAllocator 0 | 0 | 48 | memory/ClusterVConnectionCache::Entry 0 | 0 |560 | memory/cacheContAllocator 0 | 0 |112 | memory/inControlAllocator 0 | 0 |112 | memory/outControlAllocator 0 | 0 | 32 | memory/byteBankAllocator 0 | 0 |576 | memory/clusterVCAllocator 0 |
[jira] [Commented] (TS-1001) reload the changes in dns.resolv_conf
[ https://issues.apache.org/jira/browse/TS-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135813#comment-13135813 ] Conan Wang commented on TS-1001: I mean manually reload the resolv_conf. ATS cannot reload that currently. > reload the changes in dns.resolv_conf > - > > Key: TS-1001 > URL: https://issues.apache.org/jira/browse/TS-1001 > Project: Traffic Server > Issue Type: Wish > Components: DNS >Reporter: Conan Wang >Priority: Trivial > > a trivial wish: ATS can reload (traffic_line -x) resolv.conf if nameserver > changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-994) X-Forwarded-For should follow the squid way
[ https://issues.apache.org/jira/browse/TS-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132497#comment-13132497 ] Conan Wang commented on TS-994: --- My backend server will log X-Forwarded-For, and the additional leading space bother me when parsing the log. > X-Forwarded-For should follow the squid way > --- > > Key: TS-994 > URL: https://issues.apache.org/jira/browse/TS-994 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Minor > Fix For: 3.1.1 > > Attachments: XFF.patch > > > TS will append the IP in the format of: > {code} > X-Forwarded-For: 127.0.0.1, 10.32.102.41\r\n > {code} > while http://en.wikipedia.org/wiki/X-Forwarded-For says: > {code} > X-Forwarded-For: client1, proxy1, proxy2 > {code} > there is 2 spaces in TS X-Forwarded-For header. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-824) Range requests that result in cache refresh give 200 status response with full contents
[ https://issues.apache.org/jira/browse/TS-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128400#comment-13128400 ] Conan Wang commented on TS-824: --- Can I apply the commit's patch to 3.0.1 code? > Range requests that result in cache refresh give 200 status response with > full contents > --- > > Key: TS-824 > URL: https://issues.apache.org/jira/browse/TS-824 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.1 > > Attachments: TS-824-2.diff > > > If you send a request with a Range: header to TS when it has full cached > contents that need to be refreshed, and they get back a status 304 response > indicating that the cached contents are up to date, TS will respond to the > client with a status 200 response, and the full contents. So the content is > served from cache, but do not go through the transform to only return partial > bytes and a status 206 response like it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128090#comment-13128090 ] Conan Wang commented on TS-948: --- My test: return TS_ERROR directly in TSRemapInit {code} TSReturnCodeâ‹… TSRemapInit(TSRemapInterface* api_info, char* errbuf, int errbuf_size) { return TS_ERROR; {code} {code} [Oct 15 14:51:28.411] Server {0x7fff739b6960} WARNING: Failed to initialize plugin /Users/conan/box/ts-trunk/libexec/trafficserver/add_header.so (non-zero retval) ... bailing out FATAL: UnixUDPNet.cc:295: failed assert `event != NULL` /Users/conan/box/ts-trunk/bin/traffic_server - STACK TRACE: 0 libtsutil.3.dylib 0x000105af6e3b ink_fatal_va + 283 1 libtsutil.3.dylib 0x000105af7144 ink_fatal + 356 2 libtsutil.3.dylib 0x000105af458f _ink_assert + 271 3 traffic_server 0x0001051c9ed5 _ZN19UDPReadContinuationD1Ev + 85 4 traffic_server 0x0001051ca056 _ZN14ClassAllocatorI19UDPReadContinuationE4$_44D1Ev + 24 5 traffic_server 0x0001051d452d _ZN14ClassAllocatorI19UDPReadContinuationED1Ev + 37 6 traffic_server 0x0001051ca07b __tcf_3 + 27 7 libsystem_c.dylib 0x7fff85e547c8 __cxa_finalize + 274 8 libsystem_c.dylib 0x7fff85e54652 exit + 18 9 traffic_server 0x000104ff0b18 _ZN10UrlRewrite17load_remap_pluginEPPciP11url_mappingS0_iiPi + 4552 10 traffic_server 0x000104ffa383 _ZN10UrlRewrite10BuildTableEv + 12757 11 traffic_server 0x000104ffdcf5 _ZN10UrlRewriteC1EPKc + 2165 12 traffic_server 0x000104ef9ada _Z18init_reverse_proxyv + 138 13 traffic_server 0x000104f623bd _Z20init_HttpProxyServerv + 13 14 traffic_server 0x000104ecebd9 main + 6073 15 traffic_server 0x000104e582a4 start + 52 [Oct 15 14:51:28.747] Manager {0x7fff739b6960} ERROR: [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6: Abort trap: 6 {code} > do not reload bad remap.config > -- > > Key: TS-948 > URL: https://issues.apache.org/jira/browse/TS-948 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Management >Affects Versions: 3.1.0, 3.0.1 >Reporter: Conan Wang >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.1 > > > traffic_server will exit if exists bad rules in remap.config, whenever > startup or reload ( traffic_line -x ). > If remap.config is not edited correctly, the server/cluster will crash when > reloading. > It's better to pre-check the remap table and not switch to the new table if > remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127257#comment-13127257 ] Conan Wang commented on TS-948: --- Fix that. But returning TS_ERROR in "TSRemapInit" also crashes. Sorry for missing that test in advance. > do not reload bad remap.config > -- > > Key: TS-948 > URL: https://issues.apache.org/jira/browse/TS-948 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Management >Affects Versions: 3.1.0, 3.0.1 >Reporter: Conan Wang >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.1 > > > traffic_server will exit if exists bad rules in remap.config, whenever > startup or reload ( traffic_line -x ). > If remap.config is not edited correctly, the server/cluster will crash when > reloading. > It's better to pre-check the remap table and not switch to the new table if > remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125568#comment-13125568 ] Conan Wang commented on TS-948: --- My test: 1. duplicate remap rule and adding non-exist remap plugin now will not crash running ATS. I can see "WARNING: failed to reload remap.config, not replacing!" in traffic.out. 2. though bad remap.config is not reloaded, seem "TSRemapDeleteInstance" (TSfree ihandle) of my remap plugin is called according to my debug log. However, my remap plugin work well like before, that is, I can still retrieve the stored variable in ihandle. I don't know whether there is potential problem. 3. return TS_ERROR in "TSRemapNewInstance" still crash. {code} Server {0x1079f6000} ERROR: Failed to create new instance for plugin /Users/conan/box/ts-trunk/libexec/trafficserver/add_header.so (non-zero retval)... bailing out FATAL: UnixUDPNet.cc:295: failed assert `event != NULL` /Users/conan/box/ts-trunk/bin/traffic_server - STACK TRACE: 0 libtsutil.3.dylib 0x000102fb05ab ink_fatal_va + 283 1 libtsutil.3.dylib 0x000102fb08b4 ink_fatal + 356 2 libtsutil.3.dylib 0x000102fadcff _ink_assert + 271 3 traffic_server 0x000102684f45 _ZN19UDPReadContinuationD1Ev + 85 4 traffic_server 0x0001026850c6 _ZN14ClassAllocatorI19UDPReadContinuationE4$_44D1Ev + 24 5 traffic_server 0x00010268f59d _ZN14ClassAllocatorI19UDPReadContinuationED1Ev + 37 6 traffic_server 0x0001026850eb __tcf_3 + 27 7 libsystem_c.dylib 0x7fff872217c8 __cxa_finalize + 274 8 libsystem_c.dylib 0x7fff87221652 exit + 18 9 traffic_server 0x0001024aca9c _ZN10UrlRewrite17load_remap_pluginEPPciP11url_mappingS0_iiPi + 8284 10 traffic_server 0x0001024b5473 _ZN10UrlRewrite10BuildTableEv + 12757 11 traffic_server 0x0001024b8dc5 _ZN10UrlRewriteC1EPKc + 2165 12 traffic_server 0x0001023b450e _Z16reloadUrlRewritev + 350 13 traffic_server 0x0001023b5296 _ZN21UR_UpdateContinuation19file_update_handlerEiPv + 24 14 traffic_server 0x0001023d7434 _ZN12Continuation11handleEventEiPv + 148 15 traffic_server 0x0001026a787a _ZN7EThread13process_eventEP5Eventi + 418 16 traffic_server 0x0001026a6c85 _ZN7EThread7executeEv + 191 17 traffic_server 0x0001026a6174 _ZL21spawn_thread_internalPv + 132 18 libsystem_c.dylib 0x7fff8722e8bf _pthread_start + 335 19 libsystem_c.dylib 0x7fff87231b75 thread_start + 13 {code} > do not reload bad remap.config > -- > > Key: TS-948 > URL: https://issues.apache.org/jira/browse/TS-948 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Management >Affects Versions: 3.1.0, 3.0.1 >Reporter: Conan Wang >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.1.1 > > > traffic_server will exit if exists bad rules in remap.config, whenever > startup or reload ( traffic_line -x ). > If remap.config is not edited correctly, the server/cluster will crash when > reloading. > It's better to pre-check the remap table and not switch to the new table if > remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-824) Range requests that result in cache refresh give 200 status response with full contents
[ https://issues.apache.org/jira/browse/TS-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123362#comment-13123362 ] Conan Wang commented on TS-824: --- Diff works in my test case. curl -H "Range: bytes=1-2" > Range requests that result in cache refresh give 200 status response with > full contents > --- > > Key: TS-824 > URL: https://issues.apache.org/jira/browse/TS-824 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.1 > > Attachments: TS-824-2.diff > > > If you send a request with a Range: header to TS when it has full cached > contents that need to be refreshed, and they get back a status 304 response > indicating that the cached contents are up to date, TS will respond to the > client with a status 200 response, and the full contents. So the content is > served from cache, but do not go through the transform to only return partial > bytes and a status 206 response like it should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira