[jira] [Commented] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates

2012-03-27 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-03-26 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-03-08 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-03-04 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-03-02 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-03-01 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-02-14 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2012-02-01 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-12-04 Thread Conan Wang (Commented) (JIRA) 

[ 
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 ?

2011-10-29 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-26 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-21 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-16 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-14 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-13 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-11 Thread Conan Wang (Commented) (JIRA) 

[ 
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

2011-10-07 Thread Conan Wang (Commented) (JIRA) 

[ 
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