date:20130319


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

Yunkai Zhang updated TS-1749:
-

Attachment: 0001-TS-1749-one-LOCAL-record-break-the-continuity-of-NOD.patch

one LOCAL record break the continuity of NODE records

All RECT_NODE Records must be placed continuously! The code depends on it to
calculate offset when reading RECT_NODE records received from other nodes in
the some cluster.


 Stats cluster values among nodes are not consistent
 ---

 Key: TS-1749
 URL: https://issues.apache.org/jira/browse/TS-1749
 Project: Traffic Server
  Issue Type: Bug
  Components: Stats
Reporter: Yunkai Zhang
 Attachments: 
 0001-TS-1749-one-LOCAL-record-break-the-continuity-of-NOD.patch


 In my testing, I setup a cluster consist of two nodes: test62/test63.
 And then, using jtest to do some requests for node test62.
 Finally, I stopped jtest, and picked up some stats value shown as below from 
 these two ndoes:
 {code}
 Node test62:
 ---
 [root@test62 ~]# list-cluster.sh
  proxy.process.http.origin_server_request_document_total_size=0
  proxy.process.http.origin_server_request_header_total_size=271218334
  proxy.node.http.origin_server_total_request_bytes=271218334
  proxy.cluster.http.origin_server_total_request_bytes=271218334
 Node test63:
 ---
 [root@test63 ~]# list-cluster.sh
  proxy.process.http.origin_server_request_document_total_size=0
  proxy.process.http.origin_server_request_header_total_size=0
  proxy.node.http.origin_server_total_request_bytes=0
  proxy.cluster.http.origin_server_total_request_bytes=23973809347
 {code}
 Obviously, the stats cluster value: 
 *proxy.cluster.http.origin_server_total_request_bytes* is not consistent 
 among two nodes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1756) TS cluster Segmentation fault

2013-03-19 Thread helaku (JIRA)


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

helaku updated TS-1756:
---

Description: 
centos 5.9 x64 ts3.2.4  debug log



[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] State 
Transition: API_CACHE_LOOKUP_COMPLETE - SERVE_FROM_CACHE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] 
perform_cache_write_action CACHE_DO_SERVE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect) 
[HttpSM::do_redirect]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect) 
[HttpTunnel::deallocate_postdata_copy_buffers]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding 
producer 'cache read'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding 
consumer 'user agent'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) tunnel_run 
started, p_arg is NULL
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_cs) tcp_init_cwnd_set 1
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466] 
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466] 
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
[SelectFromAlternates] # alternates = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
[SelectFromAlternates] 1 alternates for this cached doc
[alts] There are 1 alternates for this request header.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match 
for ACCEPT CHARSET
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match 
for ACCEPT ENCODING
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
[calculate_quality_accept_language_match]: response hdr does not have 
content-language.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Content-Type 
and Accept 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Content-Type 
and Accept-Charset 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
Content-Encoding and Accept-Encoding 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021] 
[HttpSM::main_handler, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021] 
[HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
Content-Language and Accept-Language 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Mult's 
Quality Factor: 1.002001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) --End 
of Alternate--
NOTE: Traffic Server received Sig 11: Segmentation fault
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)   type = 
'image', subtype = 'jpeg'/usr/local/trafficserver-3.2.4/bin/traffic_server - 
STACK TRACE: 

[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)   Using 
default image vary headers
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: Returning final Q = 1.002
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: Returning final Q = 1.002
[alts]  alternate #1 (Q = 1.002) has these request/response hdrs:
GET http://117.7.92.116/line_head/3/220x165/50e7cac997a17.jpg HTTP/1.1
Accept: */*
Referer: http://www.xg.com.cn/
Accept-Language: zh-CN
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; 
Trident/5.0; qihu theworld)
Accept-Encoding: gzip
Host: img2a.xg-img.com.cn
Client-ip: 113.132.246.226
X-Forwarded-For: 113.132.246.226

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 19 Mar 2013 06:43:05 GMT
Content-Type: image/jpeg
Connection: keep-alive
Last-Modified: Sat, 05

[jira] [Updated] (TS-1756) Crash report: kill_tunnel

2013-03-19 Thread Zhao Yongming (JIRA)


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

Zhao Yongming updated TS-1756:
--

  Component/s: HTTP
   Core
   Clustering
Fix Version/s: 3.3.2
  Description: 
centos 5.9 x64 ts3.2.4  debug log


{code}
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] State 
Transition: API_CACHE_LOOKUP_COMPLETE - SERVE_FROM_CACHE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] 
perform_cache_write_action CACHE_DO_SERVE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect) 
[HttpSM::do_redirect]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect) 
[HttpTunnel::deallocate_postdata_copy_buffers]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding 
producer 'cache read'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding 
consumer 'user agent'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) tunnel_run 
started, p_arg is NULL
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_cs) tcp_init_cwnd_set 1
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466] 
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466] 
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
[SelectFromAlternates] # alternates = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
[SelectFromAlternates] 1 alternates for this cached doc
[alts] There are 1 alternates for this request header.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match 
for ACCEPT CHARSET
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match 
for ACCEPT ENCODING
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
[calculate_quality_accept_language_match]: response hdr does not have 
content-language.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Content-Type 
and Accept 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Content-Type 
and Accept-Charset 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
Content-Encoding and Accept-Encoding 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021] 
[HttpSM::main_handler, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021] 
[HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
Content-Language and Accept-Language 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Mult's 
Quality Factor: 1.002001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) --End 
of Alternate--
NOTE: Traffic Server received Sig 11: Segmentation fault
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)   type = 
'image', subtype = 'jpeg'/usr/local/trafficserver-3.2.4/bin/traffic_server - 
STACK TRACE: 

[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)   Using 
default image vary headers
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
CalcQualityOfMatch: Returning final Q = 1.002
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
CalcQualityOfMatch: Returning final Q = 1.002
[alts]  alternate #1 (Q = 1.002) has these request/response hdrs:
GET http://117.7.92.116/line_head/3/220x165/50e7cac997a17.jpg HTTP/1.1
Accept: */*
Referer: http://www.xg.com.cn/
Accept-Language: zh-CN
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; 
Trident/5.0; qihu theworld)
Accept-Encoding: gzip
Host: img2a.xg-img.com.cn
Client-ip: 113.132.246.226
X-Forwarded-For:

[jira] [Updated] (TS-1757) core at LogUtils::escapify_url()

2013-03-19 Thread Zhao Yongming (JIRA)


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

Zhao Yongming updated TS-1757:
--

Description: 

{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long, 
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long, 
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}

  was:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(_ZN8LogUtils12escapify_urlEP5ArenaPcmPiS2_mPKh+0x60)[0x5b8550]
/usr/bin/traffic_server(_ZN13LogAccessHttp4initEv+0xbc)[0x59864c]
/usr/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x11e)[0x59b3ce]
/usr/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x52be20]
/usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x5374d8]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x5377f8]
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(_ZN18UnixNetVConnection9mainEventEiP5Event+0x5df)[0x68989f]
/usr/bin/traffic_server(_ZN13InactivityCop16check_inactivityEiP5Event+0xa6)[0x6839b6]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6ac714]
/usr/bin/traffic_server(_ZN18PriorityEventQueue11check_readyElP7EThread+0x17b)[0x6aebab]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x12c)[0x6acd0c]
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]


 core at LogUtils::escapify_url()
 

 Key: TS-1757
 URL: https://issues.apache.org/jira/browse/TS-1757
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Bin Chen

 {code}
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/bin/traffic_server - STACK TRACE: 
 /lib64/libpthread.so.0[0x39ab20f4a0]
 /usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long, 
 int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
 /usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
 /usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
 /usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
 /usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
 /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]
 /usr/bin/traffic_server[0x68727b]
 /usr/bin/traffic_server(UnixNetVConnection::mainEvent(int, 
 Event*)+0x5df)[0x68989f]
 /usr/bin/traffic_server(InactivityCop::check_inactivity(int, 
 Event*)+0xa6)[0x6839b6]
 /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
 /usr/bin/traffic_server(PriorityEventQueue::check_ready(long, 
 EThread*)+0x17b)[0x6aebab]
 /usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]
 /usr/bin/traffic_server[0x6ab2b2]
 /lib64/libpthread.so.0[0x39ab2077f1]
 /lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1754) Warnings from stats evaluation


[ 
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606158#comment-13606158
 ] 

Yunkai Zhang commented on TS-1754:
--

Hi [~zwoop]:

I think we can remove the warning directly if you don't like it.

 Warnings from stats evaluation
 --

 Key: TS-1754
 URL: https://issues.apache.org/jira/browse/TS-1754
 Project: Traffic Server
  Issue Type: Bug
Reporter: Leif Hedstrom
 Fix For: 3.3.2


 After 5bcc19e6, I'm seeing these warnings:
 {code}
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 ...
 {code}
 There are quite a few of them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TS-1758) Remove unused overviewPage aggregation functions

Yunkai Zhang created TS-1758:


 Summary: Remove unused overviewPage aggregation functions
 Key: TS-1758
 URL: https://issues.apache.org/jira/browse/TS-1758
 Project: Traffic Server
  Issue Type: Bug
  Components: Cleanup, Stats
Reporter: Yunkai Zhang


Remove unused overviewPage aggregation functions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1758) Remove unused overviewPage aggregation functions


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

Yunkai Zhang updated TS-1758:
-

Attachment: 0001-Remove-unused-overviewPage-aggregation-functions.patch

 Remove unused overviewPage aggregation functions
 

 Key: TS-1758
 URL: https://issues.apache.org/jira/browse/TS-1758
 Project: Traffic Server
  Issue Type: Bug
  Components: Cleanup, Stats
Reporter: Yunkai Zhang
 Attachments: 
 0001-Remove-unused-overviewPage-aggregation-functions.patch


 Remove unused overviewPage aggregation functions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1756) Crash report: kill_tunnel

2013-03-19 Thread helaku (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606264#comment-13606264
 ] 

helaku commented on TS-1756:


croe dump info

#0  0x00552bdf in HttpTunnel::chain_abort_all (this=0x2aaab58e5e00, 
p=0x2aaab58e5ff8) at HttpTunnel.cc:1306
#1  0x005538b4 in HttpTunnel::kill_tunnel (this=0x2aaab58e5e00) at 
HttpTunnel.cc:490
#2  0x00513d7c in HttpSM::state_watch_for_client_abort 
(this=0x2aaab58e4290, event=104, data=value optimized out) at HttpSM.cc:876
#3  0x0051e8a4 in HttpSM::main_handler (this=0x2aaab58e4290, event=104, 
data=0xe885388) at HttpSM.cc:2447
#4  0x0065657d in read_from_net (nh=0x2ae2f1e8, vc=0xe885280, 
thread=0x2ae2c010) at ../../iocore/eventsystem/I_Continuation.h:146
#5  0x0064c252 in NetHandler::mainNetEvent (this=0x2ae2f1e8, 
event=value optimized out, e=0x2bd3b01c) at UnixNet.cc:372
#6  0x00675490 in EThread::process_event (this=0x2ae2c010, 
e=0xdba8860, calling_code=5) at I_Continuation.h:146
#7  0x00675d79 in EThread::execute (this=0x2ae2c010) at 
UnixEThread.cc:264
#8  0x004b5f6b in main (argc=value optimized out, argv=value 
optimized out) at Main.cc:1822

 Crash report: kill_tunnel
 -

 Key: TS-1756
 URL: https://issues.apache.org/jira/browse/TS-1756
 Project: Traffic Server
  Issue Type: Bug
  Components: Clustering, Core, HTTP
Affects Versions: 3.2.4
Reporter: helaku
 Fix For: 3.3.2


 centos 5.9 x64 ts3.2.4  debug log
 {code}
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] State 
 Transition: API_CACHE_LOOKUP_COMPLETE - SERVE_FROM_CACHE
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] 
 perform_cache_write_action CACHE_DO_SERVE
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect) 
 [HttpSM::do_redirect]
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect) 
 [HttpTunnel::deallocate_postdata_copy_buffers]
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding 
 producer 'cache read'
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding 
 consumer 'user agent'
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) tunnel_run 
 started, p_arg is NULL
 [Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_cs) tcp_init_cwnd_set 1
 [Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466] 
 consumer_handler [user agent VC_EVENT_WRITE_READY]
 [Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466] 
 consumer_handler [user agent VC_EVENT_WRITE_READY]
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
 [SelectFromAlternates] # alternates = 1
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
 [SelectFromAlternates] 1 alternates for this cached doc
 [alts] There are 1 alternates for this request header.
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match 
 for ACCEPT CHARSET
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match 
 for ACCEPT ENCODING
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
 [calculate_quality_accept_language_match]: response hdr does not have 
 content-language.
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
 CalcQualityOfMatch: Accept match = 1
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
 CalcQualityOfMatch: Accept match = 1
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
 Content-Type and Accept 1.00
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
 CalcQualityOfMatch: AcceptCharset match = 1.001
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
 CalcQualityOfMatch: AcceptCharset match = 1.001
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
 Content-Type and Accept-Charset 1.001000
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
 CalcQualityOfMatch: AcceptEncoding match = 1.001
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
 CalcQualityOfMatch: AcceptEncoding match = 1.001
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
 Content-Encoding and Accept-Encoding 1.001000
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) 
 CalcQualityOfMatch: AcceptLanguage match = 1
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq) 
 CalcQualityOfMatch: AcceptLanguage match = 1
 [Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021] 
 [HttpSM::main_handler, VC_EVENT_EOS]
 [Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021] 
 [HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
 [Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) 
 Content-Language and Accept-Language 1.00

[jira] [Created] (TS-1759) encouter Sig 11 while enable cluster

2013-03-19 Thread hu xiao (JIRA)

hu xiao created TS-1759:
---

 Summary: encouter Sig 11 while enable cluster
 Key: TS-1759
 URL: https://issues.apache.org/jira/browse/TS-1759
 Project: Traffic Server
  Issue Type: Bug
  Components: Clustering
Reporter: hu xiao


I have two box running ATS and they are nomally when running separately. 
But if enable cluster, they are random reboot, and have  Sig 11  in 
traffic.out.

The core.dump in gdb :

Core was generated by `traffic_server'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/trafficserver/lib/libtsutil.so.6...done.
Loaded symbols for /usr/local/trafficserver/lib/libtsutil.so.6
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/local/lib/libpcre.so.3...done.
Loaded symbols for /usr/local/lib/libpcre.so.3
Reading symbols from /usr/lib/libssl.so.6...done.
Loaded symbols for /usr/lib/libssl.so.6
Reading symbols from /lib/libcrypto.so.6...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/local/lib/libtcl85.so.1...done.
Loaded symbols for /usr/local/lib/libtcl85.so.1
Reading symbols from /usr/local/lib/libexpat.so.6...done.
Loaded symbols for /usr/local/lib/libexpat.so.6
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/lib/liblzma.so.5...done.
Loaded symbols for /usr/lib/liblzma.so.5
Reading symbols from /usr/local/lib/libexecinfo.so.1...done.
Loaded symbols for /usr/local/lib/libexecinfo.so.1
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/libsupc++.so.1...done.
Loaded symbols for /usr/lib/libsupc++.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  UnixNetVConnection::do_io_write (this=0x81b5cc240, c=0xfab8, nbytes=0, 
reader=0x0, owner=false) at Ptr.h:414
414 Ptr.h: No such file or directory.
in Ptr.h
[New Thread 8050e8c00 (LWP 100933/traffic_server)]
[New Thread 8050e8800 (LWP 100932/traffic_server)]
[New Thread 8050e8400 (LWP 100931/traffic_server)]
[New Thread 8050e8000 (LWP 100930/traffic_server)]
[New Thread 8050e7c00 (LWP 100929/traffic_server)]
[New Thread 80380e400 (LWP 100928/traffic_server)]
[New Thread 80380e000 (LWP 100927/traffic_server)]
[New Thread 80380dc00 (LWP 100926/traffic_server)]
[New Thread 80380d800 (LWP 100925/traffic_server)]
[New Thread 80380d400 (LWP 100924/traffic_server)]
[New Thread 80380d000 (LWP 100923/traffic_server)]
[New Thread 80380cc00 (LWP 100922/traffic_server)]
[New Thread 80380c800 (LWP 100921/traffic_server)]
[New Thread 80380c400 (LWP 100920/traffic_server)]
[New Thread 80380c000 (LWP 100919/traffic_server)]
[New Thread 80380bc00 (LWP 100918/traffic_server)]
[New Thread 80380b800 (LWP 100917/traffic_server)]
[New Thread 80380b400 (LWP 100916/traffic_server)]
[New Thread 80380b000 (LWP 100915/traffic_server)]
[New Thread 80380ac00 (LWP 100914/traffic_server)]
[New Thread 80380a800 (LWP 100882/traffic_server)]
[New Thread 80380a400 (LWP 100881/traffic_server)]
[New Thread 80380a000 (LWP 100877/traffic_server)]
[New Thread 803809c00 (LWP 100875/traffic_server)]
[New Thread 803809800 (LWP 100874/traffic_server)]
[New Thread 803809400 (LWP 100873/traffic_server)]
[New Thread 803809000 (LWP 100872/traffic_server)]
[New Thread 803808c00 (LWP 100871/traffic_server)]
[New Thread 803808800 (LWP 100870/traffic_server)]
[New Thread 803808400 (LWP 100869/traffic_server)]
[New Thread 803807800 (LWP 100867/traffic_server)]
[New Thread 803807400 (LWP 100241/traffic_server)]
(gdb) bt
#0  UnixNetVConnection::do_io_write (this=0x81b5cc240, c=0xfab8, nbytes=0, 
reader=0x0, owner=false) at Ptr.h:414
#1  0x00526a71 in HttpSessionManager::release_session (this=0x9aad60, 
to_release=0x8036dd860) at HttpSessionManager.cc:309
#2  0x0052ee22 in HttpSM::tunnel_handler_server (this=0x81b6c6e30, 
event=58905600, p=0x8036dd860) at HttpSM.cc:2893
#3  0x0057d92c in HttpTunnel::producer_handler (this=0x81b6c89c0, 
event=102, p=0x81b6c8bb8) at HttpTunnel.cc:1161
#4  0x0057deff in HttpTunnel::main_handler (this=0x81b6c89c0, 
event=value optimized out, data=value optimized out) at HttpTunnel.cc:1477
#5  0x0057e251 in chunked_reenable (p=0x81b6c8bb8, tunnel=0x81b6c89c0) 
at HttpTunnel.cc:73
#6  0x0057e42e in HttpTunnel::consumer_handler (this=0x81b6c89c0, 
event=101, c=0x81b6c8a68) at

[jira] [Updated] (TS-1554) http_ui should encode the URL


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

Leif Hedstrom updated TS-1554:
--

Fix Version/s: (was: 3.3.3)
   3.5.0

 http_ui should encode the URL
 -

 Key: TS-1554
 URL: https://issues.apache.org/jira/browse/TS-1554
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache, HTTP, Management
Affects Versions: 3.3.0
Reporter: Zhao Yongming
Priority: Minor
 Fix For: 3.5.0

 Attachments: tmp.png


 I have a strange url:
 {code}
 http://l.tbcdn.cn/??p/mall/base/global-v2.css,apps/tmall/header/shop/header.css,apps/tmall/header/shop/head-info.css,apps/malldetail/3.0/base.css,apps/malldetail/3.0/mui.css,apps/malldetail/3.0/css/spriter.css,apps/malldetail/3.0/css/D950.css,apps/malldetail/3.0/css/shop.css,apps/malldetail/3.0/tabbar/tabbar.css,apps/malldetail/3.0/css/sku.css,apps/malldetail/3.0/other/other.css,apps/malldetail/3.0/sku/regionSell.css,apps/malldetail/3.0/spu/spu.css,apps/malldetail/3.0/accessibility/accessibility.css?t=201210262012092220120625.css
 {code}
 which may cause the cache lookup create several deletes when you hit the 
 delete button.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1546) endless loop in unmashual may cause throttling


[ 
https://issues.apache.org/jira/browse/TS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606420#comment-13606420
 ] 

Leif Hedstrom commented on TS-1546:
---

Where's the quick fix? :)

I'm moving this to 3.3.2 now, since the fix is imminent.

 endless loop in unmashual may cause throttling
 --

 Key: TS-1546
 URL: https://issues.apache.org/jira/browse/TS-1546
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cache, HTTP
Affects Versions: 3.3.0
Reporter: Zhao Yongming
Assignee: weijin
 Fix For: 3.3.3


 we get a thread looping in the HdrHeap::unmarshal, while m_length is 0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1546) endless loop in unmashual may cause throttling


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

Leif Hedstrom updated TS-1546:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 endless loop in unmashual may cause throttling
 --

 Key: TS-1546
 URL: https://issues.apache.org/jira/browse/TS-1546
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cache, HTTP
Affects Versions: 3.3.0
Reporter: Zhao Yongming
Assignee: weijin
 Fix For: 3.3.2


 we get a thread looping in the HdrHeap::unmarshal, while m_length is 0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)


[ 
https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606426#comment-13606426
 ] 

Leif Hedstrom commented on TS-1492:
---

What's the word on this? Should we commit the fix and create a new bug for 
feature additions / changes ? James?

 if being net_connections_throttled,  ts must to be restarted?(because of 
 can't accept health checking request)
 --

 Key: TS-1492
 URL: https://issues.apache.org/jira/browse/TS-1492
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Priority: Critical
 Fix For: 3.3.3

 Attachments: backdoor_not_throttling.patch


 In our env, ts will be throttled because of many request incomming 
 simultaneously(because of frontend haproxy is restarted). But we don't expect 
 ts be restarted because of this case. we can handled this:
 1、if throttled, ts's health check request always be handled
 2、many many connection request may be handled in long time

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)


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

Leif Hedstrom updated TS-1492:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 if being net_connections_throttled,  ts must to be restarted?(because of 
 can't accept health checking request)
 --

 Key: TS-1492
 URL: https://issues.apache.org/jira/browse/TS-1492
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Priority: Critical
 Fix For: 3.3.2

 Attachments: backdoor_not_throttling.patch


 In our env, ts will be throttled because of many request incomming 
 simultaneously(because of frontend haproxy is restarted). But we don't expect 
 ts be restarted because of this case. we can handled this:
 1、if throttled, ts's health check request always be handled
 2、many many connection request may be handled in long time

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)


[ 
https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606428#comment-13606428
 ] 

Leif Hedstrom commented on TS-1492:
---

Fwiw, the patch looks reasonable to me.

 if being net_connections_throttled,  ts must to be restarted?(because of 
 can't accept health checking request)
 --

 Key: TS-1492
 URL: https://issues.apache.org/jira/browse/TS-1492
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Priority: Critical
 Fix For: 3.3.2

 Attachments: backdoor_not_throttling.patch


 In our env, ts will be throttled because of many request incomming 
 simultaneously(because of frontend haproxy is restarted). But we don't expect 
 ts be restarted because of this case. we can handled this:
 1、if throttled, ts's health check request always be handled
 2、many many connection request may be handled in long time

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1754) Warnings from stats evaluation


[ 
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606433#comment-13606433
 ] 

Leif Hedstrom commented on TS-1754:
---

Yeah, please submit a patch here, and I'll commit it.

 Warnings from stats evaluation
 --

 Key: TS-1754
 URL: https://issues.apache.org/jira/browse/TS-1754
 Project: Traffic Server
  Issue Type: Bug
Reporter: Leif Hedstrom
 Fix For: 3.3.2


 After 5bcc19e6, I'm seeing these warnings:
 {code}
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 ...
 {code}
 There are quite a few of them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1476) clang scan API: Argument with 'nonnull' attribute passed null


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

Leif Hedstrom updated TS-1476:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 clang scan API: Argument with 'nonnull' attribute passed null 
 --

 Key: TS-1476
 URL: https://issues.apache.org/jira/browse/TS-1476
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cleanup
Affects Versions: 3.3.0
Reporter: Zhao Yongming
 Fix For: 3.3.2


 7 items: http://people.apache.org/~igalic/checks/ats/latest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1477) clang scan Dead store: Dead assignment


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

Leif Hedstrom updated TS-1477:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 clang scan Dead store: Dead assignment
 --

 Key: TS-1477
 URL: https://issues.apache.org/jira/browse/TS-1477
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cleanup
Affects Versions: 3.3.0
Reporter: Zhao Yongming
 Fix For: 3.3.2


 47 items: http://people.apache.org/~igalic/checks/ats/latest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1479) clang scan Dead store: Dead initialization


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

Leif Hedstrom updated TS-1479:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 clang scan Dead store: Dead initialization
 --

 Key: TS-1479
 URL: https://issues.apache.org/jira/browse/TS-1479
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cleanup
Affects Versions: 3.3.0
Reporter: Zhao Yongming
 Fix For: 3.3.2


 12 items: http://people.apache.org/~igalic/checks/ats/latest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1754) Warnings from stats evaluation


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

Yunkai Zhang updated TS-1754:
-

Attachment: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch

 Warnings from stats evaluation
 --

 Key: TS-1754
 URL: https://issues.apache.org/jira/browse/TS-1754
 Project: Traffic Server
  Issue Type: Bug
Reporter: Leif Hedstrom
 Fix For: 3.3.2

 Attachments: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch


 After 5bcc19e6, I'm seeing these warnings:
 {code}
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 ...
 {code}
 There are quite a few of them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1478) clang scan Dead store: Dead increment


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

Leif Hedstrom updated TS-1478:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 clang scan Dead store: Dead increment
 -

 Key: TS-1478
 URL: https://issues.apache.org/jira/browse/TS-1478
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cleanup
Affects Versions: 3.3.0
Reporter: Zhao Yongming
 Fix For: 3.3.2


 29 items: http://people.apache.org/~igalic/checks/ats/latest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1480) clang scan Logic error: Called C++ object pointer is null


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

Leif Hedstrom updated TS-1480:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 clang scan Logic error: Called C++ object pointer is null
 -

 Key: TS-1480
 URL: https://issues.apache.org/jira/browse/TS-1480
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cleanup
Affects Versions: 3.3.0
Reporter: Zhao Yongming
 Fix For: 3.3.2


 22 items: http://people.apache.org/~igalic/checks/ats/latest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1481) clang scan Logic error: Dereference of null pointer


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

Leif Hedstrom updated TS-1481:
--

Fix Version/s: (was: 3.3.3)
   3.3.2

 clang scan Logic error: Dereference of null pointer
 ---

 Key: TS-1481
 URL: https://issues.apache.org/jira/browse/TS-1481
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Cleanup
Affects Versions: 3.3.0
Reporter: Zhao Yongming
 Fix For: 3.3.2


 42 items: http://people.apache.org/~igalic/checks/ats/latest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)


[ 
https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606485#comment-13606485
 ] 

James Peach commented on TS-1492:
-

I'm ok with the implementation, but I think the flag should be called 
allow_throttle rather than backdoor. I prefer that the iocore layers expose 
general mechanisms rather than specific policy. Bin Chen, can you please make 
that change, then I will commit this patch.

 if being net_connections_throttled,  ts must to be restarted?(because of 
 can't accept health checking request)
 --

 Key: TS-1492
 URL: https://issues.apache.org/jira/browse/TS-1492
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Bin Chen
Priority: Critical
 Fix For: 3.3.2

 Attachments: backdoor_not_throttling.patch


 In our env, ts will be throttled because of many request incomming 
 simultaneously(because of frontend haproxy is restarted). But we don't expect 
 ts be restarted because of this case. we can handled this:
 1、if throttled, ts's health check request always be handled
 2、many many connection request may be handled in long time

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1754) Warnings from stats evaluation


[ 
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606488#comment-13606488
 ] 

Yunkai Zhang commented on TS-1754:
--

OK, submitted.

Itime to sleep now, see you tomorrow:).

 Warnings from stats evaluation
 --

 Key: TS-1754
 URL: https://issues.apache.org/jira/browse/TS-1754
 Project: Traffic Server
  Issue Type: Bug
Reporter: Leif Hedstrom
 Fix For: 3.3.2

 Attachments: 0001-TS-1754-Remove-warning-info-in-StatBinaryEval.patch


 After 5bcc19e6, I'm seeing these warnings:
 {code}
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 [Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type 
 are RECD_NULL.
 ...
 {code}
 There are quite a few of them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-337) Cache Replacement Algorithm plug-in API


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

James Peach updated TS-337:
---

Fix Version/s: sometime

 Cache Replacement Algorithm plug-in API
 ---

 Key: TS-337
 URL: https://issues.apache.org/jira/browse/TS-337
 Project: Traffic Server
  Issue Type: New Feature
  Components: TS API
Affects Versions: 2.0.0
Reporter: Mark Nottingham
 Fix For: sometime


 New cache replacement algorithms are often proposed, and often it's not a 
 one size fits all problem; different workloads require different approaches.
 To facilitate this, TS should have a pluggable cache replacement policy API, 
 both for the memory and disk cache.
 Squid has done this to good effect; see
   http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/repl/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1026) Changes to improve docs formatting


[ 
https://issues.apache.org/jira/browse/TS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606495#comment-13606495
 ] 

James Peach commented on TS-1026:
-

Igor, what's going on with this bug?

 Changes to improve docs formatting
 --

 Key: TS-1026
 URL: https://issues.apache.org/jira/browse/TS-1026
 Project: Traffic Server
  Issue Type: Improvement
  Components: Web site
Reporter: zoe slattery
Assignee: Igor Galić
Priority: Minor
 Attachments: docspage.diff, docspage.diff, docspagethml.diff, 
 downloadshtml.diff, indexhtml.diff, indexhtml.diff, stylescss.diff, 
 stylescss.diff, stylescss.diff, stylescss.diff


 Remove the 'banner' class in styles.css and make all heading formats the 
 same. 
 Modify the docs template to use class blurbbox, this will leave margins 
 around text.
 Still to do - fix the header of docs pages.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1026) Changes to improve docs formatting


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

James Peach updated TS-1026:


Fix Version/s: sometime

 Changes to improve docs formatting
 --

 Key: TS-1026
 URL: https://issues.apache.org/jira/browse/TS-1026
 Project: Traffic Server
  Issue Type: Improvement
  Components: Web site
Reporter: zoe slattery
Assignee: Igor Galić
Priority: Minor
 Fix For: sometime

 Attachments: docspage.diff, docspage.diff, docspagethml.diff, 
 downloadshtml.diff, indexhtml.diff, indexhtml.diff, stylescss.diff, 
 stylescss.diff, stylescss.diff, stylescss.diff


 Remove the 'banner' class in styles.css and make all heading formats the 
 same. 
 Modify the docs template to use class blurbbox, this will leave margins 
 around text.
 Still to do - fix the header of docs pages.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1160) FATAL: ink_memalign: couldn't allocate 602439680 bytes at alignment 4096 - insufficient memory ts crash


[ 
https://issues.apache.org/jira/browse/TS-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606499#comment-13606499
 ] 

James Peach commented on TS-1160:
-

This looks like you don't have enough memory for the number of cache objects 
you are configuring. You will need to reduce the cache size, or tune the object 
size to be larger (see proxy.config.cache.min_average_object_size).

 FATAL: ink_memalign: couldn't allocate 602439680 bytes at alignment 4096 - 
 insufficient memory   ts crash
 -

 Key: TS-1160
 URL: https://issues.apache.org/jira/browse/TS-1160
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.3
 Environment: centos 6.0 x86_64
Reporter: bettydramit

 FATAL: ink_memalign: couldn't allocate 602439680 bytes at alignment 4096 - 
 insufficient memory
 /usr/bin/traffic_server - STACK TRACE: 
 /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x2ab0905926dd]
 /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x2ab090592838]
 /usr/lib64/trafficserver/libtsutil.so.3(ink_memalign+0x9c)[0x2ab09059414c]
 /usr/bin/traffic_server(_ZN9CacheSync9mainEventEiP5Event+0x2c8)[0x644ab8]
 /usr/bin/traffic_server(_ZN3Vol12aggWriteDoneEiP5Event+0x5d7)[0x668567]
 /usr/bin/traffic_server(_ZN13AIOThreadInfo5startEiP5Event+0x945)[0x6772d5]
 /usr/bin/traffic_server(_ZN7EThread7executeEv+0xb86)[0x6ac6a6]
 /usr/bin/traffic_server[0x6aa4a2]
 /lib64/libpthread.so.0(+0x77f1)[0x2ab0907bd7f1]
 /lib64/libc.so.6(clone+0x6d)[0x2ab092e4792d]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-467) Proxy shold not forward request headers that matches a Connection token


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

Leif Hedstrom updated TS-467:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 Proxy shold not forward request headers that matches a Connection token
 ---

 Key: TS-467
 URL: https://issues.apache.org/jira/browse/TS-467
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Leif Hedstrom
 Fix For: 3.5.0


 If a client sends a request like
 X-foobar: fum
 Connection: ,,X-foobar,,
 the proxy (Traffic Server) MUST remove the header X-foobar before forwarding 
 the request. From the RFC:
  HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the
connection-token.
 and
  A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this
field, remove and ignore any header field(s) from the message with
the same name as the connection-token.
 (Originally discovered with Coadvisor).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-469) A PUT request should invalidate a previously cached object with the same URI


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

Leif Hedstrom updated TS-469:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 A PUT request should invalidate a previously cached object with the same URI
 

 Key: TS-469
 URL: https://issues.apache.org/jira/browse/TS-469
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 2.1.6
Reporter: Leif Hedstrom
 Fix For: 3.5.0


 If the client first fetches an object with GET, and TS caches it, a 
 subsequent PUT request for the same URL should invalidate the cached object.
 (Originally discovered with Coadvisor).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-468) We should respond with a 417 if we cannot meet an expectation


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

Leif Hedstrom updated TS-468:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 We should respond with a 417 if we cannot meet an expectation
 -

 Key: TS-468
 URL: https://issues.apache.org/jira/browse/TS-468
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Leif Hedstrom
 Fix For: 3.5.0


 If the client sends an Expect: header that we cannot meet, we should return a 
 417 error. E.g.
 Expect: expect=params
 since we can't meet this expectation, we should return a 417, but instead we 
 forward this to the origin, and return with whatever it responds with.
 (Originally found using Coadvisor).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1160) FATAL: ink_memalign: couldn't allocate 602439680 bytes at alignment 4096 - insufficient memory ts crash


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

James Peach resolved TS-1160.
-

Resolution: Cannot Reproduce
  Assignee: James Peach

Resolving as Cannot Reproduce. Most likely cause is too little memory.

 FATAL: ink_memalign: couldn't allocate 602439680 bytes at alignment 4096 - 
 insufficient memory   ts crash
 -

 Key: TS-1160
 URL: https://issues.apache.org/jira/browse/TS-1160
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.3
 Environment: centos 6.0 x86_64
Reporter: bettydramit
Assignee: James Peach

 FATAL: ink_memalign: couldn't allocate 602439680 bytes at alignment 4096 - 
 insufficient memory
 /usr/bin/traffic_server - STACK TRACE: 
 /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x2ab0905926dd]
 /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x2ab090592838]
 /usr/lib64/trafficserver/libtsutil.so.3(ink_memalign+0x9c)[0x2ab09059414c]
 /usr/bin/traffic_server(_ZN9CacheSync9mainEventEiP5Event+0x2c8)[0x644ab8]
 /usr/bin/traffic_server(_ZN3Vol12aggWriteDoneEiP5Event+0x5d7)[0x668567]
 /usr/bin/traffic_server(_ZN13AIOThreadInfo5startEiP5Event+0x945)[0x6772d5]
 /usr/bin/traffic_server(_ZN7EThread7executeEv+0xb86)[0x6ac6a6]
 /usr/bin/traffic_server[0x6aa4a2]
 /lib64/libpthread.so.0(+0x77f1)[0x2ab0907bd7f1]
 /lib64/libc.so.6(clone+0x6d)[0x2ab092e4792d]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-407) traffic_server not using proxy.config.syslog_facility


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

Leif Hedstrom updated TS-407:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 traffic_server not using proxy.config.syslog_facility
 -

 Key: TS-407
 URL: https://issues.apache.org/jira/browse/TS-407
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom
 Fix For: 3.5.0


 We have this code in Main.cc:
 static int syslog_facility = LOG_DAEMON;
 // static void syslog_log_configure()
 //
 //   Reads the syslog configuration variable
 // and sets the global integer for the
 // facility and calls open log with the
 // new facility
 //
 static void
 syslog_log_configure()
 {
   char *facility_str = NULL;
   int facility;
   TS_ReadConfigStringAlloc(facility_str, proxy.config.syslog_facility);
   if (facility_str == NULL || (facility = 
 facility_string_to_int(facility_str))  0) {
 syslog(LOG_WARNING, Bad or missing syslog facility.   Defaulting to 
 LOG_DAEMON);
   } else {
 syslog_facility = facility;
 closelog();
 openlog(traffic_server, LOG_PID | LOG_NDELAY | LOG_NOWAIT, facility);
   }
 }
 But as far as I can tell, we never use syslog_facility.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1199) Out of memory: Kill process 1490 ([ET_NET 0]) score 963 or sacrifice child Killed process 1490, UID 99, ([ET_NET 0]) total-vm:10837656kB, anon-rss:7834172kB, file-rss:180kB


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

James Peach resolved TS-1199.
-

Resolution: Cannot Reproduce
  Assignee: James Peach

No steps to reproduce. Could be almost anything ...

 Out of memory: Kill process 1490 ([ET_NET 0]) score 963 or sacrifice child 
 Killed process 1490, UID 99, ([ET_NET 0]) total-vm:10837656kB, 
 anon-rss:7834172kB, file-rss:180kB 
 -

 Key: TS-1199
 URL: https://issues.apache.org/jira/browse/TS-1199
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.3
 Environment: centos 6 x86_64
Reporter: bettydramit
Assignee: James Peach

 Out of memory: Kill process 1490 ([ET_NET 0]) score 963 or sacrifice child
 Killed process 1490, UID 99, ([ET_NET 0]) total-vm:10837656kB, 
 anon-rss:7834172kB, file-rss:180kB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1352) request wait for a long time....


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

James Peach resolved TS-1352.
-

Resolution: Cannot Reproduce
  Assignee: James Peach

No steps to reproduce. If you can get this to happen again, a system call trace 
might help. You might also attach gdb to traffic_server and get a listing of 
all the threads using thread apply all backtrace.

 request wait for a long time
 

 Key: TS-1352
 URL: https://issues.apache.org/jira/browse/TS-1352
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.3.0
 Environment: centos 6.0 x86_64
Reporter: bettydramit
Assignee: James Peach

 wget -S -O /dev/null -e http_proxy=127.0.0.1 
 http://www.test.com/aa26f5b2e2184dee342df987d5aa4d3e3b62067c21aea45e61961ea96618d550.html
 --2012-07-16 16:44:15--  
 http://www.test.com/aa26f5b2e2184dee342df987d5aa4d3e3b62067c21aea45e61961ea96618d550.html
 Connecting to 127.0.0.1:80... connected.
 Proxy request sent, awaiting response...
 the /var/log/messages 
 Jul 16 16:40:51localhost traffic_cop[5248]: (test) read timeout [18 ]
 Jul 16 16:40:51localhost traffic_cop[5248]: server heartbeat failed [1]
 Jul 16 16:41:01localhost traffic_cop[5248]: server heartbeat succeeded
 Jul 16 16:44:31localhost traffic_cop[5248]: (test) read timeout [18 ]
 Jul 16 16:44:31localhost traffic_cop[5248]: server heartbeat failed [1]
 Jul 16 16:44:41localhost traffic_cop[5248]: server heartbeat succeeded

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used


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

Leif Hedstrom updated TS-829:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 socks stats cleanup - some stats are registered, but not used
 -

 Key: TS-829
 URL: https://issues.apache.org/jira/browse/TS-829
 Project: Traffic Server
  Issue Type: Bug
  Components: Network
Affects Versions: 3.0.0
Reporter: Bryan Call
Priority: Minor
 Fix For: 3.5.0


 From reviewing TS-818 I noticed that the stats that were being double 
 resisted are not used.  Some cleanup work should be done for the socks stats.
 Stats that are registered, but not used in the code:
 [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc 
  proxy.process.socks.connections_successful,
  proxy.process.socks.connections_unsuccessful,
  proxy.process.socks.connections_currently_open,
 These stats are used some tests, so maybe they should be added back into the 
 code.
 [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match 
 proxy.process.socks.connections_ *
 iocore/net/Net.cc
 mgmt/api/remote/APITestCliRemote.cc
 test/plugin/test-mgmt/test-mgmt.c
 I did however see these stats being used:
 [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ *
 proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \
 proxy/SocksProxy.cc:
 SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat);
 proxy/SocksProxy.cc:
 SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1376) ERROR: Error opening logging directory /var/log/trafficserver to perform a space check: Too many open files in system.


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

James Peach resolved TS-1376.
-

Resolution: Cannot Reproduce

Looks like you should add soome more memory to this system. Also, you probably 
want to raise the system's file descriptor limits.

  ERROR: Error opening logging directory /var/log/trafficserver to perform a 
 space check: Too many open files in  system.
 

 Key: TS-1376
 URL: https://issues.apache.org/jira/browse/TS-1376
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.3.3
 Environment: centos 6 x86_64 from git 3.3.0
Reporter: bettydramit

 [Jul 22 18:11:43.332] Server {0x2b9b6d031700} WARNING: accept thread received 
 transient error: errno = 23
 [Jul 22 18:11:43.332] Server {0x2b9b6d031700} WARNING: errno : 23 consider a 
 memory upgrade
 [Jul 22 18:11:50.990] Server {0x2b9b6cdad700} ERROR: Error opening logging 
 directory /var/log/trafficserver to perform a space check: Too many open 
 files in 
 system.
 [Jul 22 18:12:01.377] Manager {0x7feba734b7e0} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Jul 22 18:12:01.377] Manager {0x7feba734b7e0} FATAL:  (last system error 
 104: Connection reset by peer)
 [Jul 22 18:12:01.377] Manager {0x7feba734b7e0} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 [Jul 22 18:12:01.377] Manager {0x7feba734b7e0} NOTE: 
 [LocalManager::processShutdown] Executing process shutdown request.
 [Jul 22 18:12:01.377] Manager {0x7feba734b7e0} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 [Jul 22 18:12:01.377] Manager {0x7feba734b7e0} ERROR:  (last system error 32: 
 Broken pipe)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1206) stats snap file may crash during server crash


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

Leif Hedstrom updated TS-1206:
--

Fix Version/s: (was: 3.3.3)

 stats snap file may crash during server crash
 -

 Key: TS-1206
 URL: https://issues.apache.org/jira/browse/TS-1206
 Project: Traffic Server
  Issue Type: Bug
  Components: Stats
Reporter: Zhao Yongming

 when sometimes traffic_server crashed, some or all of the stats counter are 
 not updating anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1206) stats snap file may crash during server crash


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

Leif Hedstrom resolved TS-1206.
---

Resolution: Duplicate

This looks like a duplicate of TS-1545, which has more details.

 stats snap file may crash during server crash
 -

 Key: TS-1206
 URL: https://issues.apache.org/jira/browse/TS-1206
 Project: Traffic Server
  Issue Type: Bug
  Components: Stats
Reporter: Zhao Yongming

 when sometimes traffic_server crashed, some or all of the stats counter are 
 not updating anymore.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-149) Split ram and disk cache hit response times into separate metrics


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

Leif Hedstrom updated TS-149:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 Split ram and disk cache hit response times into separate metrics
 -

 Key: TS-149
 URL: https://issues.apache.org/jira/browse/TS-149
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cache
Reporter: Anirban
Priority: Minor
 Fix For: 3.5.0


 Split ram and disk cache hit response times into separate metrics
 Original description
 by Stephen Bisordi from Yahoo
 It appears that the response time for ram cache hits and disk cache hits is 
 captured as a single metric
 (transaction_totaltime.hit_fresh).  Would it be possible to split this into 
 two separate metrics, or to add a ram cache
 hit result code to the log to differentiate between ram and disk hits 
 (similar to Squid's TCP_MEM_HIT)?
 This change would allow for quicker troubleshooting of certain issues such as 
 poor disk performance.
   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1451) Non-standard permissions for configuration files


[ 
https://issues.apache.org/jira/browse/TS-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606521#comment-13606521
 ] 

James Peach commented on TS-1451:
-

This looks ok on trunk:

flathead:trafficserver jpeach$ ls -l trafficserver-release 
-rw-r--r--  1 root  nobody  23 Mar 18 13:40 trafficserver-release
flathead:trafficserver jpeach$ ls -ld body_factory
drwxr-xr-x  3 nobody  nobody  102 Mar 18 13:40 body_factory
flathead:trafficserver jpeach$ ls -ld body_factory/default
drwxr-xr-x  28 nobody  nobody  952 Mar 18 13:40 body_factory/default

flathead:trafficserver jpeach$ ls -l body_factory/default/*
-rw-r--r--  1 nobody  nobody  679 Mar 18 13:40 body_factory/default/README
-rw-r--r--  1 nobody  nobody  249 Mar 18 13:40 
body_factory/default/access#denied
-rw-r--r--  1 nobody  nobody  264 Mar 18 13:40 
body_factory/default/access#proxy_auth_required
-rw-r--r--  1 nobody  nobody  435 Mar 18 13:40 
body_factory/default/access#redirect_url
-rw-r--r--  1 nobody  nobody  281 Mar 18 13:40 
body_factory/default/access#ssl_forbidden
-rw-r--r--  1 nobody  nobody  340 Mar 18 13:40 
body_factory/default/cache#not_in_cache
-rw-r--r--  1 nobody  nobody  237 Mar 18 13:40 
body_factory/default/cache#read_error
-rw-r--r--  1 nobody  nobody  258 Mar 18 13:40 
body_factory/default/congestion#retryAfter
-rw-r--r--  1 nobody  nobody  405 Mar 18 13:40 
body_factory/default/connect#dns_failed
-rw-r--r--  1 nobody  nobody  250 Mar 18 13:40 
body_factory/default/connect#failed_connect
-rw-r--r--  1 nobody  nobody  302 Mar 18 13:40 
body_factory/default/connect#hangup
-rw-r--r--  1 nobody  nobody  217 Mar 18 13:40 body_factory/default/default
-rw-r--r--  1 nobody  nobody  462 Mar 18 13:40 
body_factory/default/interception#no_host
-rw-r--r--  1 nobody  nobody  298 Mar 18 13:40 
body_factory/default/redirect#moved_temporarily
-rw-r--r--  1 nobody  nobody  347 Mar 18 13:40 
body_factory/default/request#cycle_detected
-rw-r--r--  1 nobody  nobody  287 Mar 18 13:40 
body_factory/default/request#no_content_length
-rw-r--r--  1 nobody  nobody  447 Mar 18 13:40 
body_factory/default/request#no_host
-rw-r--r--  1 nobody  nobody  289 Mar 18 13:40 
body_factory/default/request#scheme_unsupported
-rw-r--r--  1 nobody  nobody  230 Mar 18 13:40 
body_factory/default/request#syntax_error
-rw-r--r--  1 nobody  nobody  263 Mar 18 13:40 
body_factory/default/response#bad_response
-rw-r--r--  1 nobody  nobody  304 Mar 18 13:40 
body_factory/default/response#bad_version
-rw-r--r--  1 nobody  nobody  246 Mar 18 13:40 
body_factory/default/timeout#activity
-rw-r--r--  1 nobody  nobody  266 Mar 18 13:40 
body_factory/default/timeout#inactivity
-rw-r--r--  1 nobody  nobody  289 Mar 18 13:40 
body_factory/default/transcoding#unsupported
-rw-r--r--  1 nobody  nobody  300 Mar 18 13:40 
body_factory/default/urlrouting#no_mapping



 Non-standard permissions for configuration files
 

 Key: TS-1451
 URL: https://issues.apache.org/jira/browse/TS-1451
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration
Affects Versions: 3.2.0
Reporter: Arno Toell
Priority: Minor

 ATS by default installs some configuration files (or rather: 
 pseudo-configuration files) using non-standard permissions.
 These are files in question:
 /etc/trafficserver/body_factory/ 0775 (should probably be 0755)
 /etc/trafficserver/body_factory/default/ (likewise)
 /etc/trafficserver/trafficserver-release 0664 (should be 0644 I think)
 This *may* also affect trunk, I didn't check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached


[ 
https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606525#comment-13606525
 ] 

Leif Hedstrom commented on TS-621:
--

Heh, this is becoming quite a novel. What shall we do here ? This would be 
great to get into v3.4.0 release, but is it safe to do so ?

 writing 0 bytes to the HTTP cache means only update the header... need a new 
 API: update_header_only() to allow 0 byte files to be cached
 -

 Key: TS-621
 URL: https://issues.apache.org/jira/browse/TS-621
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache
Affects Versions: 2.1.5
Reporter: John Plevyak
 Fix For: 3.3.3

 Attachments: force_empty.diff, 
 TS-621_cluster_zero_size_objects.patch, ts-621-jp-1.patch, ts-621-jp-2.patch, 
 ts-621-jp-3.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?


[ 
https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606526#comment-13606526
 ] 

Leif Hedstrom commented on TS-608:
--

Wow, this is an old patch. Mohan or anyone in Taobao, is this patch still 
relevant? If so, can you rebase it for current master, and post again?

 Is HttpSessionManager::purge_keepalives()  too aggressive?
 --

 Key: TS-608
 URL: https://issues.apache.org/jira/browse/TS-608
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Leif Hedstrom
 Fix For: 3.3.3

 Attachments: TS-608.patch


 It seems that if we trigger the max server connections, we call this purge 
 function in the session manager, which will close all currently open 
 keep-alive connections. This seems very aggressive, why not limit it to say 
 only removing 10% of each bucket or some such? Also, how does this work 
 together with per-origin limits? Ideally, if the per-origin limits are in 
 place, we would only purge sessions that are for the IP we wish to connect to 
 ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1451) Non-standard permissions for configuration files


[ 
https://issues.apache.org/jira/browse/TS-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606528#comment-13606528
 ] 

James Peach commented on TS-1451:
-

Arno, is this still a problem on master?

 Non-standard permissions for configuration files
 

 Key: TS-1451
 URL: https://issues.apache.org/jira/browse/TS-1451
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration
Affects Versions: 3.2.0
Reporter: Arno Toell
Priority: Minor

 ATS by default installs some configuration files (or rather: 
 pseudo-configuration files) using non-standard permissions.
 These are files in question:
 /etc/trafficserver/body_factory/ 0775 (should probably be 0755)
 /etc/trafficserver/body_factory/default/ (likewise)
 /etc/trafficserver/trafficserver-release 0664 (should be 0644 I think)
 This *may* also affect trunk, I didn't check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?


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

Leif Hedstrom updated TS-608:
-

Fix Version/s: (was: 3.3.3)
   3.3.2

 Is HttpSessionManager::purge_keepalives()  too aggressive?
 --

 Key: TS-608
 URL: https://issues.apache.org/jira/browse/TS-608
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Leif Hedstrom
 Fix For: 3.3.2

 Attachments: TS-608.patch


 It seems that if we trigger the max server connections, we call this purge 
 function in the session manager, which will close all currently open 
 keep-alive connections. This seems very aggressive, why not limit it to say 
 only removing 10% of each bucket or some such? Also, how does this work 
 together with per-origin limits? Ideally, if the per-origin limits are in 
 place, we would only purge sessions that are for the IP we wish to connect to 
 ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1451) Non-standard permissions for configuration files


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

James Peach reassigned TS-1451:
---

Assignee: Arno Toell

 Non-standard permissions for configuration files
 

 Key: TS-1451
 URL: https://issues.apache.org/jira/browse/TS-1451
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration
Affects Versions: 3.2.0
Reporter: Arno Toell
Assignee: Arno Toell
Priority: Minor

 ATS by default installs some configuration files (or rather: 
 pseudo-configuration files) using non-standard permissions.
 These are files in question:
 /etc/trafficserver/body_factory/ 0775 (should probably be 0755)
 /etc/trafficserver/body_factory/default/ (likewise)
 /etc/trafficserver/trafficserver-release 0664 (should be 0644 I think)
 This *may* also affect trunk, I didn't check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1451) Non-standard permissions for configuration files


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

James Peach updated TS-1451:


Fix Version/s: 3.3.2

 Non-standard permissions for configuration files
 

 Key: TS-1451
 URL: https://issues.apache.org/jira/browse/TS-1451
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration
Affects Versions: 3.2.0
Reporter: Arno Toell
Assignee: Arno Toell
Priority: Minor
 Fix For: 3.3.2


 ATS by default installs some configuration files (or rather: 
 pseudo-configuration files) using non-standard permissions.
 These are files in question:
 /etc/trafficserver/body_factory/ 0775 (should probably be 0755)
 /etc/trafficserver/body_factory/default/ (likewise)
 /etc/trafficserver/trafficserver-release 0664 (should be 0644 I think)
 This *may* also affect trunk, I didn't check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-302) -fstrict-aliasing optimizer generates bad code

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

Leif Hedstrom updated TS-302:
-

Fix Version/s: (was: sometime)
3.5.0

-fstrict-aliasing optimizer generates bad code
--

Key: TS-302
URL: https://issues.apache.org/jira/browse/TS-302
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Reporter: Miles Libbey
Priority: Minor
Fix For: 3.5.0

Attachments: no-no-fstrict-alias.patch

(moving from yahoo bug 525119)
Original description
by Leif Hedstrom 4 years ago at 2005-12-16 08:41
Not sure if this is a compiler bug or a code issue on our side, but enabling
the
-fstrict-aliasing optimization option generates faulty code. This optimization
technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm
explicitly
turning it off with
-O3 -fno-strict-aliasing
This solves the problem where the traffic server would return data of 0 or 1
length out of the cache. This initially looked like the cache corruption
problem, but is completely different and unrelated. The cache corruption
problem
has been fixed and closed.
I'm opening this bug as a reminder, at some point we should isolate which code
triggers the strict-aliasing problem, and confirm if it's a compiler bug or a
problem in our code.

Comment 1
by Michael Bigby 4 years ago at 2005-12-16 09:07:40
I'm recommending that we get Ed's input on this. He may some insight compiler
issues...

Comment 2
by Leif Hedstrom 4 years ago at 2005-12-16 10:02:07
That'd be great!
We haven't had a chance yet to review the code that might be affecting this,
it's obviously something with unions and how the compiler handles
storage/alignment on the members.

Comment 3
by Ed Hall 4 years ago at 2006-03-03 11:46:52
This is with gcc 2.95.3, correct? There have been a number of complaints
around
the 'net about problems with -fstrict-aliasing. I've not really looked very
deeply into it, though I should mention that certain C code was known at the
time to malfunction when by-the-standard aliasing rules were enforced
(starting
with the Linux kernel).
In essense, the -fstrict-aliasing optimizations assume that any particular
part
of memory accessed via a specific type of pointer won't be accessed as another
type. There are a set of optimizations that are safe only when it can be
guaranteed that a given bit of memory hasn't been manipulated via pointer; if
the compiler assumes that the rather arcane C aliasing rules have been
followed
(aliasing in this case meaning accessing a given bit of memory with more
than
one type of pointer), there are more situations where such optimizations can
be
applied. Code which uses type casts where unions might be more appropriate is
the most likely to break aliasing rules.
In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying
the
C aliasing rules, and has added warnings for obvious violations. It's never
been clear to me if gcc 2.95.3 was actually broken or not, or if there simply
was a lot of code out there that ran afoul of the standard.

Comment 4
by Leif Hedstrom 4 years ago at 2006-03-03 12:50:22
Actually, the problem only occured after we converted the code from gcc-2.9x
to
gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands
and
thousands), so maybe we should try again to compile without the
-fno-strict-aliasing, and see if gcc will point us to some places where we do
dangerous things. The code does some very scary things manipulating objects
directly, by byte-offsets for instance.
I think it's pretty easy to reproduce the problem, it basically renders the
cache completely useless, returning objects of size 0 or 1.

Comment 5
by Ed Hall 4 years ago at 2006-03-03 16:44:04
Ah, that makes sense. I just checked, and the -fstrict-aliasing option wasn't
part of the -O2 optimizations on gcc 2.95, but got added sometime during gcc 3
development.

Comment 6
by Ed Hall 4 years ago at 2006-03-03 16:46:43
(Just to be clear, -fstrict-aliasing was *available* with gcc 2.95.3, it just
wasn't activated by the -O optimization flags.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-378) FIx the strict-aliasing rules warnings


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

Leif Hedstrom resolved TS-378.
--

   Resolution: Duplicate
Fix Version/s: (was: 3.3.3)

marking this as duplicate of TS-302, which has some further details.

 FIx the strict-aliasing rules warnings
 --

 Key: TS-378
 URL: https://issues.apache.org/jira/browse/TS-378
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cleanup
Affects Versions: 3.0.0
Reporter: Mladen Turk
Assignee: Mladen Turk
Priority: Minor

 Currently the compile fails with -fstrict-aliasing.
 The reason is mostly using int pointers to read or write 64 bit numbers
 Eg. INK_MD5.cc has
 struct INK_MD5
 {
   uint64 b[2];
   uint32 word(int i)
   {
 uint32 *p = (uint32 *)  b[0];
 return p[i];
   }
  ...
 };
 Such things can be easily fixed and properly handled using unions
 (they are invented for that)
 struct INK_MD5
 {
   union {
  uint64 q[2];
  uint32 u[4];
  unsigned char b[16];
   } s;
   uint32 word(int i)
   {
 return s.w[i];
   }
  ...
 };

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1485) 3.2.x - CPU sets for Solaris


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

James Peach updated TS-1485:


Fix Version/s: 3.2.4

 3.2.x - CPU sets for Solaris
 

 Key: TS-1485
 URL: https://issues.apache.org/jira/browse/TS-1485
 Project: Traffic Server
  Issue Type: Wish
Affects Versions: 3.2.0
Reporter: Igor Galić
 Fix For: 3.2.4


 Please backport eefd111a8e841b4a73d934ff81487317e640af13
 to 3.2.x!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1485) 3.2.x - CPU sets for Solaris


[ 
https://issues.apache.org/jira/browse/TS-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606534#comment-13606534
 ] 

James Peach commented on TS-1485:
-

Schedule for 3.2.4

 3.2.x - CPU sets for Solaris
 

 Key: TS-1485
 URL: https://issues.apache.org/jira/browse/TS-1485
 Project: Traffic Server
  Issue Type: Wish
Affects Versions: 3.2.0
Reporter: Igor Galić
 Fix For: 3.2.4


 Please backport eefd111a8e841b4a73d934ff81487317e640af13
 to 3.2.x!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1485) 3.2.x - CPU sets for Solaris


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

James Peach reassigned TS-1485:
---

Assignee: Igor Galić

Igor, do still want this for 3.2.4?

 3.2.x - CPU sets for Solaris
 

 Key: TS-1485
 URL: https://issues.apache.org/jira/browse/TS-1485
 Project: Traffic Server
  Issue Type: Wish
Affects Versions: 3.2.0
Reporter: Igor Galić
Assignee: Igor Galić
 Fix For: 3.2.4


 Please backport eefd111a8e841b4a73d934ff81487317e640af13
 to 3.2.x!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-152) Cleanup Diags

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

Leif Hedstrom updated TS-152:
-

Fix Version/s: (was: 3.3.3)
3.5.0

Cleanup Diags
-

Key: TS-152
URL: https://issues.apache.org/jira/browse/TS-152
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Reporter: John Plevyak
Priority: Minor
Fix For: 3.5.0

The use of Diags functions and tags is inconsistent and they are often
wrapped with
incompatible macros in each module.
Following the discussion in https://issues.apache.org/jira/browse/TS-130 I
propose that we:
1. use Diags() for diagnostic messages to appear from all builds
2. use Debug() for diagnostic messages to appear from only DEBUG builds,
replacing this with myriad of competing macros for this behavior in
different moduels
3. organize the existing tags hierarchically and document then (at least) in
the master P_.h file for
each module.
4. rename the -T argument form --debug_tags to --diag_tags
5. remove #define of IOCORE_MacheFatal to fprintf in P_EventSystem.h (what
the heck is that?)
and other wrappers for these functions and standardize them
6. remove unused and competing ink_error.h/cc functions ink_fatal ink_dprintf
etc.
and convert to the Fatal/Diags versions.
These are all vestiges of when ink_xxx.h were C headers and InkFoo.h were
C++
headers. Which accounts for the redundancy.
Because . is special in regex we could use:
cache_write_open
cache_write_ready
etc.
so we could use -Tcache* or -Tcache_write* to capture different levels of
events.
Ideas welcome.
john

[jira] [Updated] (TS-214) On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe)


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

Leif Hedstrom updated TS-214:
-

Fix Version/s: (was: 3.3.3)
   3.5.0

 On Solaris, use port_send to signal async events to a waiting thread (e.g. 
 like eventfd/pipe)
 -

 Key: TS-214
 URL: https://issues.apache.org/jira/browse/TS-214
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.0.0
 Environment: OpenSolaris
Reporter: John Plevyak
Assignee: Theo Schlossnagle
 Fix For: 3.5.0


 We should use port_send to signal async events to a waiting thread (e.g. like 
 eventfd/pipe).
 http://developers.sun.com/solaris/articles/event_completion.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-214) On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe)


[ 
https://issues.apache.org/jira/browse/TS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606537#comment-13606537
 ] 

Leif Hedstrom commented on TS-214:
--

Moved out to v3.5.0, move back to 3.3.x if there will be work on this in the 
next 1-2 months.

 On Solaris, use port_send to signal async events to a waiting thread (e.g. 
 like eventfd/pipe)
 -

 Key: TS-214
 URL: https://issues.apache.org/jira/browse/TS-214
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.0.0
 Environment: OpenSolaris
Reporter: John Plevyak
Assignee: Theo Schlossnagle
 Fix For: 3.5.0


 We should use port_send to signal async events to a waiting thread (e.g. like 
 eventfd/pipe).
 http://developers.sun.com/solaris/articles/event_completion.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1586) spdy plugin doesn't build under latest trunk


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

James Peach updated TS-1586:


Fix Version/s: 3.3.2

 spdy plugin doesn't build under latest trunk
 

 Key: TS-1586
 URL: https://issues.apache.org/jira/browse/TS-1586
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.3.1
 Environment: llvm/clang from trunk (on Linux, haven't tested on other 
 platforms yet)
Reporter: Igor Galić
Assignee: Igor Galić
 Fix For: 3.3.2

 Attachments: restrict.patch


 {noformat}
 Making all in spdy
 gmake[3]: Entering directory 
 `/home/igalic/src/asf/trafficserver/CLANG/plugins/experimental/spdy'
 /bin/sh ../../../libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H 
 -I. -I../../../../plugins/experimental/spdy -I../../../lib/ts  
 -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api 
 -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
 -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG  -std=c++11 -ggdb3 
 -Werror -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF 
 .deps/message.Tpo -c -o message.lo `test -f 'lib/spdy/message.cc' || echo 
 '../../../../plugins/experimental/spdy/'`lib/spdy/message.cc
 libtool: compile:  clang++ -DHAVE_CONFIG_H -I. 
 -I../../../../plugins/experimental/spdy -I../../../lib/ts 
 -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api 
 -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
 -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG -std=c++11 -ggdb3 -Werror 
 -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF 
 .deps/message.Tpo -c 
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc  -fPIC -DPIC -o 
 .libs/message.o
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:72:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 extract(const uint8_t __restrict * ptr) {
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:80:32: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 extractuint8_t(const uint8_t __restrict * ptr) {
  ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:85:30: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 insert(const T val, uint8_t __restrict * ptr) {
  ^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:91:33: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 extract_stream_id(const uint8_t __restrict * ptr)
   ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:97:46: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 insert_stream_id(uint32_t stream_id, uint8_t __restrict * ptr)
  ^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:104:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:133:44: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const message_header msg, uint8_t __restrict * ptr, size_t len)
^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:153:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:170:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:185:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:200:48: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const rst_stream_message msg, uint8_t __restrict * ptr, size_t len)
^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:356:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is

[jira] [Assigned] (TS-1586) spdy plugin doesn't build under latest trunk


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

James Peach reassigned TS-1586:
---

Assignee: Igor Galić

Igor, can you update one of the vagrant boxes so that we can repro this?

 spdy plugin doesn't build under latest trunk
 

 Key: TS-1586
 URL: https://issues.apache.org/jira/browse/TS-1586
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.3.1
 Environment: llvm/clang from trunk (on Linux, haven't tested on other 
 platforms yet)
Reporter: Igor Galić
Assignee: Igor Galić
 Attachments: restrict.patch


 {noformat}
 Making all in spdy
 gmake[3]: Entering directory 
 `/home/igalic/src/asf/trafficserver/CLANG/plugins/experimental/spdy'
 /bin/sh ../../../libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H 
 -I. -I../../../../plugins/experimental/spdy -I../../../lib/ts  
 -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api 
 -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
 -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG  -std=c++11 -ggdb3 
 -Werror -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF 
 .deps/message.Tpo -c -o message.lo `test -f 'lib/spdy/message.cc' || echo 
 '../../../../plugins/experimental/spdy/'`lib/spdy/message.cc
 libtool: compile:  clang++ -DHAVE_CONFIG_H -I. 
 -I../../../../plugins/experimental/spdy -I../../../lib/ts 
 -I../../../../plugins/experimental/spdy/lib -I../../../proxy/api 
 -D__STDC_FORMAT_MACROS=1 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
 -D_GNU_SOURCE -D_REENTRANT -Dlinux -DDEBUG -D_DEBUG -std=c++11 -ggdb3 -Werror 
 -Qunused-arguments -Wno-invalid-offsetof -MT message.lo -MD -MP -MF 
 .deps/message.Tpo -c 
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc  -fPIC -DPIC -o 
 .libs/message.o
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:72:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 extract(const uint8_t __restrict * ptr) {
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:80:32: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 extractuint8_t(const uint8_t __restrict * ptr) {
  ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:85:30: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 insert(const T val, uint8_t __restrict * ptr) {
  ^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:91:33: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 extract_stream_id(const uint8_t __restrict * ptr)
   ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:97:46: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 insert_stream_id(uint32_t stream_id, uint8_t __restrict * ptr)
  ^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:104:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:133:44: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const message_header msg, uint8_t __restrict * ptr, size_t len)
^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:153:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:170:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:185:23: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const uint8_t __restrict * ptr, size_t len)
 ~~^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:200:48: error: 
 restrict requires a pointer or reference ('uint8_t' (aka 'unsigned char') is 
 invalid)
 const rst_stream_message msg, uint8_t __restrict * ptr, size_t len)
^~
 ../../../../plugins/experimental/spdy/lib/spdy/message.cc:356:23: error: 
 restrict requires a

[jira] [Commented] (TS-315) Add switch to disable config file generation/runtime behavior changing

[
https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606544#comment-13606544
]

Leif Hedstrom commented on TS-315:
--

This also might be a thing to attach to the clustering configs, such that if
cluster config is disabled, we don't (re) write our configs to disk.

Add switch to disable config file generation/runtime behavior changing
--

Key: TS-315
URL: https://issues.apache.org/jira/browse/TS-315
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Miles Libbey
Priority: Minor
Fix For: 3.3.3

(was yahoo bug 1863676)
Original description
by Michael S. Fischer 2 years ago at 2008-04-09 09:52
In production, in order to improve site stability, it is imperative that TS
never accidentally overwrite its own
configuration files.
For this reason, we'd like to request a switch be added to TS, preferably via
the command line, that disables all
automatic configuration file generation or other runtime behavioral changes
initiated by any form of IPC other than
'traffic_line -x' (including the web interface, etc.)

Comment 1
by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17
A very crucial request, in my opinion. If TS needs to be able to read
command-line config changes on the fly, these
changes should be stored in another config file (for example
remap.config.local instead of remap.config). We have a
patch config package that overwrites 4 of the config files under
/home/conf/ts/, and with all packages
we'd like to think that the content of these files can't change outside our
control.

Comment 2
by Bryan Call 2 years ago at 2008-04-09 11:02:46
traffic_line -x doesn't modify the configuration, it reloads the
configuration files. If we want to have an option for
this it would be good to have it as an option configuration file (CONFIG
proxy.config.write_protect INT 1).
It would be an equivalent of write protecting floppies (ahh the memories)...

Comment 3
by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09
I don't think it would be a good idea to have this in the configuration file,
as it would introduce a chicken/egg
problem.

Comment 4
by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17
So I'm not 100% positive that this isn't just a bad interaction. Now, it's
only
triggered when trafficserver is running, but usually what ends up happening
is that we get a records.config which
looks like it's the default config that comes with the trafficserver package.
It's possible it's all one and the same issue, or we might have two issues.

[jira] [Updated] (TS-1623) in transparent mode the logs are missing the hostname of the site


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

James Peach updated TS-1623:


Summary:  in transparent mode the logs are missing the hostname of the site 
 (was: Transparent Mode)

  in transparent mode the logs are missing the hostname of the site
 --

 Key: TS-1623
 URL: https://issues.apache.org/jira/browse/TS-1623
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: ivan

 Hello in transparent mode the logs are missing the hostname of the site.
 1355456955.026 139 192.168.9.192 TCP_MISS/200 5009 GET 
 http:///news/tbn/G2-ssYSsPG4PnM/11.jpg - DIRECT/nt3.ggpht.com image/jpeg -
 When I explicitly go to the non-transparent mode. The log has the correct 
 host name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing

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

Leif Hedstrom updated TS-315:
-

Fix Version/s: (was: 3.3.3)
3.3.4

Add switch to disable config file generation/runtime behavior changing
--

Key: TS-315
URL: https://issues.apache.org/jira/browse/TS-315
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Miles Libbey
Priority: Minor
Fix For: 3.3.4

Comment 3
by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09
I don't think it would be a good idea to have this in the configuration file,
as it would introduce a chicken/egg
problem.

[jira] [Assigned] (TS-1623) in transparent mode the logs are missing the hostname of the site


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

James Peach reassigned TS-1623:
---

Assignee: Alan M. Carroll

Alan, do you know about this?

  in transparent mode the logs are missing the hostname of the site
 --

 Key: TS-1623
 URL: https://issues.apache.org/jira/browse/TS-1623
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: ivan
Assignee: Alan M. Carroll

 Hello in transparent mode the logs are missing the hostname of the site.
 1355456955.026 139 192.168.9.192 TCP_MISS/200 5009 GET 
 http:///news/tbn/G2-ssYSsPG4PnM/11.jpg - DIRECT/nt3.ggpht.com image/jpeg -
 When I explicitly go to the non-transparent mode. The log has the correct 
 host name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1623) in transparent mode the logs are missing the hostname of the site


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

James Peach updated TS-1623:


Fix Version/s: sometime

  in transparent mode the logs are missing the hostname of the site
 --

 Key: TS-1623
 URL: https://issues.apache.org/jira/browse/TS-1623
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: ivan
Assignee: Alan M. Carroll
 Fix For: sometime


 Hello in transparent mode the logs are missing the hostname of the site.
 1355456955.026 139 192.168.9.192 TCP_MISS/200 5009 GET 
 http:///news/tbn/G2-ssYSsPG4PnM/11.jpg - DIRECT/nt3.ggpht.com image/jpeg -
 When I explicitly go to the non-transparent mode. The log has the correct 
 host name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1604) Request body gets stripped from DELETE


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

James Peach resolved TS-1604.
-

Resolution: Duplicate
  Assignee: Uri Shachar

Duplicate of TS-1627 as per Uri.

 Request body gets stripped from DELETE
 --

 Key: TS-1604
 URL: https://issues.apache.org/jira/browse/TS-1604
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.2.0
Reporter: Mathias Biilmann Christensen
Assignee: Uri Shachar

 Traffic Server strips the request body from DELETE requests, while leaving 
 the Content-Length header intact.
 Ideally Traffic Server should preserve the request body if a Content-Length 
 header is present. There's nothing explicitly forbidding request bodys for 
 DELETE requests in the HTTP spec.
 If the body is stripped, the Content-Length header should be removed as well, 
 otherwise backend servers might hang while waiting for the request body.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1623) in transparent mode the logs are missing the hostname of the site


[ 
https://issues.apache.org/jira/browse/TS-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606553#comment-13606553
 ] 

Leif Hedstrom commented on TS-1623:
---

Curious as to why this happens in transparent proxy only, and not in forward 
proxy?

  in transparent mode the logs are missing the hostname of the site
 --

 Key: TS-1623
 URL: https://issues.apache.org/jira/browse/TS-1623
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: ivan
Assignee: Alan M. Carroll
 Fix For: sometime


 Hello in transparent mode the logs are missing the hostname of the site.
 1355456955.026 139 192.168.9.192 TCP_MISS/200 5009 GET 
 http:///news/tbn/G2-ssYSsPG4PnM/11.jpg - DIRECT/nt3.ggpht.com image/jpeg -
 When I explicitly go to the non-transparent mode. The log has the correct 
 host name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1598) Coring in SSL


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

James Peach updated TS-1598:


Fix Version/s: sometime

 Coring in SSL
 -

 Key: TS-1598
 URL: https://issues.apache.org/jira/browse/TS-1598
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Affects Versions: 3.2.0
 Environment: RHEL6.2 64bit
Reporter: Abhishek Nayani
 Fix For: sometime


 (gdb) bt
 #0  0x00390ac88c5b in memcpy () from /lib64/libc.so.6
 #1  0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10
 #2  0x003f9670 in ?? () from /usr/lib64/libssl.so.10
 #3  0x0066eaf7 in ssl_read_from_net (nh=value optimized out, 
 vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at 
 SSLNetVConnection.cc:135
 #4  0x0066f3b0 in SSLNetVConnection::net_read_io 
 (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at 
 SSLNetVConnection.cc:288
 #5  0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, 
 event=value optimized out, e=value optimized out) at UnixNet.cc:381
 #6  0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, 
 calling_code=5) at I_Continuation.h:146
 #7  EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) 
 at UnixEThread.cc:142
 #8  0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at 
 UnixEThread.cc:264
 #9  0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88
 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0
 #11 0x00390ace76dd in clone () from /lib64/libc.so.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1598) Coring in SSL


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

James Peach reassigned TS-1598:
---

Assignee: Bryan Call

Not much to go on here. Bryan, if you don't think this is going to make 
progress feel free to close it out.

 Coring in SSL
 -

 Key: TS-1598
 URL: https://issues.apache.org/jira/browse/TS-1598
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Affects Versions: 3.2.0
 Environment: RHEL6.2 64bit
Reporter: Abhishek Nayani
Assignee: Bryan Call
 Fix For: sometime


 (gdb) bt
 #0  0x00390ac88c5b in memcpy () from /lib64/libc.so.6
 #1  0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10
 #2  0x003f9670 in ?? () from /usr/lib64/libssl.so.10
 #3  0x0066eaf7 in ssl_read_from_net (nh=value optimized out, 
 vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at 
 SSLNetVConnection.cc:135
 #4  0x0066f3b0 in SSLNetVConnection::net_read_io 
 (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at 
 SSLNetVConnection.cc:288
 #5  0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, 
 event=value optimized out, e=value optimized out) at UnixNet.cc:381
 #6  0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, 
 calling_code=5) at I_Continuation.h:146
 #7  EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) 
 at UnixEThread.cc:142
 #8  0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at 
 UnixEThread.cc:264
 #9  0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88
 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0
 #11 0x00390ace76dd in clone () from /lib64/libc.so.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1592) crash at HttpCompat::parse_tok_list


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

James Peach updated TS-1592:


Fix Version/s: sometime

 crash at HttpCompat::parse_tok_list
 ---

 Key: TS-1592
 URL: https://issues.apache.org/jira/browse/TS-1592
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.2.0
 Environment: full_cluster
Reporter: Bin Chen
Assignee: taorui
 Fix For: sometime


 {code}
 Program terminated with signal 11, Segmentation fault.
 #0  HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=value 
 optimized out, string=value optimized out, 
 len=value optimized out, sep=59 ';') at HttpCompat.cc:77
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=value 
 optimized out, string=value optimized out, 
 len=value optimized out, sep=59 ';') at HttpCompat.cc:77
 #1  0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118, 
 content_field=value optimized out)
 at ../../proxy/hdrs/HttpCompat.h:92
 #2  HttpTransactCache::calculate_quality_of_accept_match 
 (accept_field=0x2b3da50ab118, content_field=value optimized out)
 at HttpTransactCache.cc:519
 #3  0x00530cf6 in HttpTransactCache::calculate_quality_of_match 
 (http_config_param=0x2b3da6a074a0, 
 client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0, 
 obj_origin_server_response=0x2b3f4748d600)
 at HttpTransactCache.cc:327
 #4  0x00531a7d in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2b3d94749be0, 
 client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at 
 HttpTransactCache.cc:214
 #5  0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0, 
 event=3900, e=0x0) at CacheRead.cc:1019
 #6  0x00604348 in handleEvent (this=0x2b3d94749ae0, event=value 
 optimized out, e=value optimized out)
 at ../../iocore/eventsystem/I_Continuation.h:146
 #7  CacheVC::handleReadDone (this=0x2b3d94749ae0, event=value optimized 
 out, e=value optimized out) at Cache.cc:1952
 #8  0x00608035 in handleEvent (this=value optimized out, 
 event=value optimized out, data=value optimized out)
 at ../../iocore/eventsystem/I_Continuation.h:146
 #9  AIOCallbackInternal::io_complete (this=value optimized out, 
 event=value optimized out, data=value optimized out)
 at ../../iocore/aio/P_AIO.h:80
 #10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10, 
 calling_code=1) at I_Continuation.h:146
 #11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1) 
 at UnixEThread.cc:189
 #12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at 
 UnixEThread.cc:240
 #13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
 #14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
 #15 0x0034bf8e570d in clone () from /lib64/libc.so.6
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1592) crash at HttpCompat::parse_tok_list


[ 
https://issues.apache.org/jira/browse/TS-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606557#comment-13606557
 ] 

James Peach commented on TS-1592:
-

Any update on this? Do we know how to reproduce?

 crash at HttpCompat::parse_tok_list
 ---

 Key: TS-1592
 URL: https://issues.apache.org/jira/browse/TS-1592
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.2.0
 Environment: full_cluster
Reporter: Bin Chen
Assignee: taorui
 Fix For: sometime


 {code}
 Program terminated with signal 11, Segmentation fault.
 #0  HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=value 
 optimized out, string=value optimized out, 
 len=value optimized out, sep=59 ';') at HttpCompat.cc:77
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HttpCompat.cc:77:2565:beg:0x5a7990
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  HttpCompat::parse_tok_list (list=0x2b3d7aca86f0, trim_quotes=value 
 optimized out, string=value optimized out, 
 len=value optimized out, sep=59 ';') at HttpCompat.cc:77
 #1  0x0052e4fc in parse_semicolon_list (accept_field=0x2b3da50ab118, 
 content_field=value optimized out)
 at ../../proxy/hdrs/HttpCompat.h:92
 #2  HttpTransactCache::calculate_quality_of_accept_match 
 (accept_field=0x2b3da50ab118, content_field=value optimized out)
 at HttpTransactCache.cc:519
 #3  0x00530cf6 in HttpTransactCache::calculate_quality_of_match 
 (http_config_param=0x2b3da6a074a0, 
 client_request=0x2b3d94749ba0, obj_client_request=0x2b3f4748d5c0, 
 obj_origin_server_response=0x2b3f4748d600)
 at HttpTransactCache.cc:327
 #4  0x00531a7d in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2b3d94749be0, 
 client_request=0x2b3d94749ba0, http_config_params=0x2b3da6a074a0) at 
 HttpTransactCache.cc:214
 #5  0x006245e5 in CacheVC::openReadStartHead (this=0x2b3d94749ae0, 
 event=3900, e=0x0) at CacheRead.cc:1019
 #6  0x00604348 in handleEvent (this=0x2b3d94749ae0, event=value 
 optimized out, e=value optimized out)
 at ../../iocore/eventsystem/I_Continuation.h:146
 #7  CacheVC::handleReadDone (this=0x2b3d94749ae0, event=value optimized 
 out, e=value optimized out) at Cache.cc:1952
 #8  0x00608035 in handleEvent (this=value optimized out, 
 event=value optimized out, data=value optimized out)
 at ../../iocore/eventsystem/I_Continuation.h:146
 #9  AIOCallbackInternal::io_complete (this=value optimized out, 
 event=value optimized out, data=value optimized out)
 at ../../iocore/aio/P_AIO.h:80
 #10 0x0066ae94 in handleEvent (this=0x2b3d7a42b010, e=0x213ec10, 
 calling_code=1) at I_Continuation.h:146
 #11 EThread::process_event (this=0x2b3d7a42b010, e=0x213ec10, calling_code=1) 
 at UnixEThread.cc:189
 #12 0x0066b773 in EThread::execute (this=0x2b3d7a42b010) at 
 UnixEThread.cc:240
 #13 0x00669c72 in spawn_thread_internal (a=0x1785910) at Thread.cc:88
 #14 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
 #15 0x0034bf8e570d in clone () from /lib64/libc.so.6
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-709) proxy.config.output.logfile is not configurable


[ 
https://issues.apache.org/jira/browse/TS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606558#comment-13606558
 ] 

Leif Hedstrom commented on TS-709:
--

Igor,I tested this with:

CONFIG proxy.config.output.logfile STRING leif.out

and that seemed to work as expected. I don't however see anything related to 
setting it to stdout etc., where in the code or docs do you see that ?

Please advice.

 proxy.config.output.logfile is not configurable
 ---

 Key: TS-709
 URL: https://issues.apache.org/jira/browse/TS-709
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration
Reporter: Igor Galić
Priority: Minor
 Fix For: 3.3.3


 The code suggests that proxy.config.output.logfile can be set to stdout, 
 stderr, syslog, diagslog or an arbitrary file (if relative, then relative to 
 $logdir).
 Setting it however, has no effect, the debug output always goes to stderr.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-1723) remove libiconv dependency


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

James Peach resolved TS-1723.
-

   Resolution: Fixed
Fix Version/s: 3.3.1

 remove libiconv dependency
 --

 Key: TS-1723
 URL: https://issues.apache.org/jira/browse/TS-1723
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, Packaging, Portability
Reporter: James Peach
Assignee: Igor Galić
 Fix For: 3.3.1


 libiconv is only used by ink_utf8_to_latin1(), and that function is never 
 called. Let's remove the whole thing!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1712) Double Free Issue with Basic Auth Type Plugin


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

James Peach updated TS-1712:


Fix Version/s: sometime

 Double Free Issue with Basic Auth Type Plugin
 -

 Key: TS-1712
 URL: https://issues.apache.org/jira/browse/TS-1712
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: Valerie Thompson
 Fix For: sometime


 I am creating a new plugin based off of basic-auth.c example from 3.0.5 
 version of ATS. When I load the plugin and start running traffic through it I 
 am getting memory issues and eventually crashes. 
 I plan on having a username and password for my plugin, and as I add more 
 features, the more unstable everything becomes. Today I stripped everything 
 down to the bare minimum and ran it as and here is an example of memory 
 issues, below. Let me know if you need further information.
 uname info for the type of box I'm running on:
 2.6.32-279.5.1.el6.x86_64 #1 SMP Tue Aug 14 16:11:42 CDT 2012 x86_64 x86_64 
 x86_64 GNU/Linux
 {quote}
 *** glibc detected *** /usr/bin/traffic_server: double free or corruption 
 (!prev): 0x030c4ab0 ***
 === Backtrace: =
 /lib64/libc.so.6[0x3197275916]
 /lib64/libc.so.6[0x3197278443]
 /usr/lib64/trafficserver/plugins/ena-auth.so(+0x16a0)[0x2b051fc026a0]
 /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52d3e5]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x35a)[0x5222fa]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xac3)[0x537753]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
 /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
 /usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0x280)[0x52e760]
 /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
 /usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x202)[0x510d22]
 /usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x4be)[0x65a41e]
 /usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x170)[0x638910]
 /usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x510674]
 /usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0x151)[0x521ab1]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6f3)[0x537383]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
 /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7fd)[0x53748d]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
 /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x53828a]
 /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x278)[0x52d138]
 /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x536e7a]
 /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x9f)[0x5209df]
 /usr/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x5ab)[0x52c06b]
 /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x5309a8]
 /usr/bin/traffic_server[0x68314b]
 /usr/bin/traffic_server[0x685c71]
 /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67e782]
 /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6aaff4]
 /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6ab983]
 /usr/bin/traffic_server(main+0x1128)[0x4c0878]
 /lib64/libc.so.6(__libc_start_main+0xfd)[0x319721ecdd]
 /usr/bin/traffic_server[0x47e149]
 === Memory map: 
 0040-00759000 r-xp  fd:01 668319 
 /usr/bin/traffic_server
 00959000-0096d000 rw-p

[jira] [Resolved] (TS-1722) Compiling trunk on Fedora15/i686 fails


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

James Peach resolved TS-1722.
-

Resolution: Cannot Reproduce

Does this still reproduce with master? I know we build on Fedora 18.

 Compiling trunk on Fedora15/i686 fails
 --

 Key: TS-1722
 URL: https://issues.apache.org/jira/browse/TS-1722
 Project: Traffic Server
  Issue Type: Bug
Reporter: C.R.

 Compiling newest trunk I receive the error message:
 make[2]: Entering directory `/home/tr/x/trafficserver/iocore/eventsystem'
 g++ -DHAVE_CONFIG_H  -I. -I../../lib/ts  -I../../lib -I../../lib/records 
 -I../../lib/ts -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE 
 -D_REENTRANT -Dlinux  -march=i586 -g -pipe -Wall -Werror -O3 
 -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof 
 -MT UnixEventProcessor.o -MD -MP -MF .deps/UnixEventProcessor.Tpo -c -o 
 UnixEventProcessor.o UnixEventProcessor.cc
 UnixEventProcessor.cc: In member function ‘virtual int 
 EventProcessor::start(int)’:
 UnixEventProcessor.cc:186:194: error: format ‘%u’ expects argument of type 
 ‘unsigned int’, but argument 8 has type ‘ink_thread {aka long unsigned int}’ 
 [-Werror=format]
 UnixEventProcessor.cc:188:240: error: format ‘%u’ expects argument of type 
 ‘unsigned int’, but argument 8 has type ‘ink_thread {aka long unsigned int}’ 
 [-Werror=format]
 cc1plus: all warnings being treated as errors
 make[2]: *** [UnixEventProcessor.o] Error 1
 This happens on a Fedora release 15 system running 2.6.43.8-1.fc15.i686.PAE 
 #1 SMP Mon Jun 4 20:21:39 UTC 2012 i686 i686 i386 GNU/Linux

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1717) static library build fails with duplicate symbols


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

James Peach updated TS-1717:


Fix Version/s: 3.3.2

 static library build fails with duplicate symbols
 -

 Key: TS-1717
 URL: https://issues.apache.org/jira/browse/TS-1717
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
 Fix For: 3.3.2


 fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static 
  make -j  sudo make install
 ...
   CXXLDtraffic_manager
   AR   libmgmt_p.a
 duplicate symbol _diags in:
 Main.o
 ../lib/ts/.libs/libtsutil.a(Diags.o)
 ld: 1 duplicate symbol for architecture x86_64
 example/app-template/app-template.cc://Diags *diags = NULL;
 iocore/aio/test_AIO.i:Diags *diags;
 iocore/cluster/test_I_Cluster.cc:Diags *diags;
 iocore/cluster/test_P_Cluster.cc:Diags *diags;
 iocore/dns/test_I_DNS.cc:Diags *diags;
 iocore/dns/test_P_DNS.cc:Diags *diags;
 iocore/eventsystem/test_Buffer.cc:Diags *diags;
 iocore/eventsystem/test_Event.i:Diags *diags;
 iocore/hostdb/test_I_HostDB.cc:Diags *diags;
 iocore/hostdb/test_P_HostDB.cc:Diags *diags;
 iocore/net/test_I_Net.cc:Diags *diags;
 iocore/net/test_I_UDPNet.cc:Diags *diags;
 iocore/net/test_P_Net.cc:Diags *diags;
 iocore/net/test_P_UDPNet.cc:Diags *diags;
 iocore/utils/diags.i://Diags *diags;
 lib/records/I_RecCore.h:int RecSetDiags(Diags * diags);
 lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL);
 lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * 
 diags = NULL);
 lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags);
 lib/records/RecCore.cc:Diags *g_diags = NULL;
 lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags)
 lib/records/RecCore.cc:RecSetDiags(Diags * _diags)
 lib/records/RecLocal.cc:RecLocalInit(Diags * _diags)
 lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags)
 lib/records/RecUtils.cc:extern Diags *g_diags;
 lib/records/test_I_RecLocal.cc:Diags *diags = NULL;
 lib/records/test_RecProcess.i:Diags *diags = NULL;
 lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL;
 lib/ts/Diags.h:extern inkcoreapi Diags *diags;
 mgmt/Main.cc:inkcoreapi Diags *diags;
 proxy/DiagsConfig.h:  Diags *diags;
 proxy/Initialize.h:extern Diags *diags;
 proxy/Main.cc://inkcoreapi Diags *diags = NULL;
 proxy/hdrs/load_http_hdr.cc://Diags *diags;
 proxy/logging/LogStandalone.cc:Diags *diags = NULL;
 Additionally, AFAICT diags.i is not used and can be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1717) static library build fails with duplicate symbols


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

James Peach reassigned TS-1717:
---

Assignee: James Peach

Aiming for 3.3.2.

 static library build fails with duplicate symbols
 -

 Key: TS-1717
 URL: https://issues.apache.org/jira/browse/TS-1717
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.2


 fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static 
  make -j  sudo make install
 ...
   CXXLDtraffic_manager
   AR   libmgmt_p.a
 duplicate symbol _diags in:
 Main.o
 ../lib/ts/.libs/libtsutil.a(Diags.o)
 ld: 1 duplicate symbol for architecture x86_64
 example/app-template/app-template.cc://Diags *diags = NULL;
 iocore/aio/test_AIO.i:Diags *diags;
 iocore/cluster/test_I_Cluster.cc:Diags *diags;
 iocore/cluster/test_P_Cluster.cc:Diags *diags;
 iocore/dns/test_I_DNS.cc:Diags *diags;
 iocore/dns/test_P_DNS.cc:Diags *diags;
 iocore/eventsystem/test_Buffer.cc:Diags *diags;
 iocore/eventsystem/test_Event.i:Diags *diags;
 iocore/hostdb/test_I_HostDB.cc:Diags *diags;
 iocore/hostdb/test_P_HostDB.cc:Diags *diags;
 iocore/net/test_I_Net.cc:Diags *diags;
 iocore/net/test_I_UDPNet.cc:Diags *diags;
 iocore/net/test_P_Net.cc:Diags *diags;
 iocore/net/test_P_UDPNet.cc:Diags *diags;
 iocore/utils/diags.i://Diags *diags;
 lib/records/I_RecCore.h:int RecSetDiags(Diags * diags);
 lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL);
 lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * 
 diags = NULL);
 lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags);
 lib/records/RecCore.cc:Diags *g_diags = NULL;
 lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags)
 lib/records/RecCore.cc:RecSetDiags(Diags * _diags)
 lib/records/RecLocal.cc:RecLocalInit(Diags * _diags)
 lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags)
 lib/records/RecUtils.cc:extern Diags *g_diags;
 lib/records/test_I_RecLocal.cc:Diags *diags = NULL;
 lib/records/test_RecProcess.i:Diags *diags = NULL;
 lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL;
 lib/ts/Diags.h:extern inkcoreapi Diags *diags;
 mgmt/Main.cc:inkcoreapi Diags *diags;
 proxy/DiagsConfig.h:  Diags *diags;
 proxy/Initialize.h:extern Diags *diags;
 proxy/Main.cc://inkcoreapi Diags *diags = NULL;
 proxy/hdrs/load_http_hdr.cc://Diags *diags;
 proxy/logging/LogStandalone.cc:Diags *diags = NULL;
 Additionally, AFAICT diags.i is not used and can be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1698) thread/pthread mis-match on Solaris 10


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

James Peach reassigned TS-1698:
---

Assignee: Igor Galić

 thread/pthread mis-match on Solaris 10
 --

 Key: TS-1698
 URL: https://issues.apache.org/jira/browse/TS-1698
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Igor Galić
Assignee: Igor Galić
 Fix For: 3.3.2

 Attachments: ink_pthead.patch


 {noformat}
   CXX  UnixEventProcessor.o
 UnixEventProcessor.cc: In member function 'virtual int 
 EventProcessor::start(int)':
 UnixEventProcessor.cc:186:7: error: format '%lu' expects argument of type 
 'long unsigned int', but argument 8 has type 'ink_thread {aka unsigned int}' 
 [-Werror=format]
 UnixEventProcessor.cc:188:9: error: format '%lu' expects argument of type 
 'long unsigned int', but argument 8 has type 'ink_thread {aka unsigned int}' 
 [-Werror=format]
 cc1plus: all warnings being treated as errors
 gmake[2]: *** [UnixEventProcessor.o] Error 1
 gmake[2]: Leaving directory 
 `/export/home/buildbot/slave5/tserver-solaris-trunk-debug/build/iocore/eventsystem'
 gmake[1]: *** [all-recursive] Error 1
 {noformat}
 This seems to be caused by our naïve code to distinguish between different 
 platforms:
 {code}
 #include P_EventSystem.h  /* MAGIC_EDITING_TAG */
 #include sched.h
 #if TS_USE_HWLOC
 #if HAVE_HWLOC_H
 #include hwloc.h
 #endif
 #if HAVE_SCHED_H
 #include sched.h
 #if !defined(solaris)  !defined(freebsd)
 typedef cpu_set_t ink_cpuset_t;
 #define PTR_FMT PRIuPTR
 #endif
 #endif
 #if HAVE_SYS_PARAM_H
 #include sys/param.h
 #endif
 #if HAVE_SYS_CPUSET_H
 #include sys/cpuset.h
 typedef cpuset_t ink_cpuset_t;
 #define PTR_FMT p
 #endif
 #if HAVE_PTHREAD_NP_H
 #include pthread_np.h
 #endif
 #if HAVE_SYS_PSET_H
 #include sys/pset.h
 typedef psetid_t ink_cpuset_t;
 #define PTR_FMT PRIuPTR
 #endif
 #if HAVE_SYS_TYPES_H
 #include sys/types.h
 #endif
 #endif
 #include ink_defs.h
 #if TS_USE_HWLOC
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1698) thread/pthread mis-match on Solaris 10


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

James Peach updated TS-1698:


Fix Version/s: 3.3.2

 thread/pthread mis-match on Solaris 10
 --

 Key: TS-1698
 URL: https://issues.apache.org/jira/browse/TS-1698
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Igor Galić
 Fix For: 3.3.2

 Attachments: ink_pthead.patch


 {noformat}
   CXX  UnixEventProcessor.o
 UnixEventProcessor.cc: In member function 'virtual int 
 EventProcessor::start(int)':
 UnixEventProcessor.cc:186:7: error: format '%lu' expects argument of type 
 'long unsigned int', but argument 8 has type 'ink_thread {aka unsigned int}' 
 [-Werror=format]
 UnixEventProcessor.cc:188:9: error: format '%lu' expects argument of type 
 'long unsigned int', but argument 8 has type 'ink_thread {aka unsigned int}' 
 [-Werror=format]
 cc1plus: all warnings being treated as errors
 gmake[2]: *** [UnixEventProcessor.o] Error 1
 gmake[2]: Leaving directory 
 `/export/home/buildbot/slave5/tserver-solaris-trunk-debug/build/iocore/eventsystem'
 gmake[1]: *** [all-recursive] Error 1
 {noformat}
 This seems to be caused by our naïve code to distinguish between different 
 platforms:
 {code}
 #include P_EventSystem.h  /* MAGIC_EDITING_TAG */
 #include sched.h
 #if TS_USE_HWLOC
 #if HAVE_HWLOC_H
 #include hwloc.h
 #endif
 #if HAVE_SCHED_H
 #include sched.h
 #if !defined(solaris)  !defined(freebsd)
 typedef cpu_set_t ink_cpuset_t;
 #define PTR_FMT PRIuPTR
 #endif
 #endif
 #if HAVE_SYS_PARAM_H
 #include sys/param.h
 #endif
 #if HAVE_SYS_CPUSET_H
 #include sys/cpuset.h
 typedef cpuset_t ink_cpuset_t;
 #define PTR_FMT p
 #endif
 #if HAVE_PTHREAD_NP_H
 #include pthread_np.h
 #endif
 #if HAVE_SYS_PSET_H
 #include sys/pset.h
 typedef psetid_t ink_cpuset_t;
 #define PTR_FMT PRIuPTR
 #endif
 #if HAVE_SYS_TYPES_H
 #include sys/types.h
 #endif
 #endif
 #include ink_defs.h
 #if TS_USE_HWLOC
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1695) test_certlookup fails on FreeBSD


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

James Peach updated TS-1695:


Component/s: Portability

 test_certlookup fails on FreeBSD
 

 Key: TS-1695
 URL: https://issues.apache.org/jira/browse/TS-1695
 Project: Traffic Server
  Issue Type: Bug
  Components: Portability
Reporter: Igor Galić

 {noformat}
 Reading symbols from 
 /tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
 [New process 100244]
 [New Thread 803806400 (LWP 100244)]
 Core was generated by `test_certlookup'.
 Program terminated with signal 10, Bus error.
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 (gdb) bt
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 #1  0x000802cc8c74 in free () from /lib/libc.so.7
 #2  0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear 
 (this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
 #3  0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
 #4  0x00403c11 in SSLContextStorage::~SSLContextStorage 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
 #5  0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0, 
 __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
 #6  0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0 
 regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8 
 regressionTest_SSLCertificateLookup+24)
 at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
 #7  0x00080085eff6 in start_test (t=0x60daa0 
 regressionTest_SSLCertificateLookup) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
 #8  0x00080085f404 in RegressionTest::run (atest=0x0) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
 #9  0x00402ce0 in main (argc=1, argv=0x7fffd470) at 
 /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
 (gdb)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1695) test_certlookup fails on FreeBSD


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

James Peach updated TS-1695:


Fix Version/s: 3.3.2

 test_certlookup fails on FreeBSD
 

 Key: TS-1695
 URL: https://issues.apache.org/jira/browse/TS-1695
 Project: Traffic Server
  Issue Type: Bug
  Components: Portability
Reporter: Igor Galić
  Labels: freebsd
 Fix For: 3.3.2


 {noformat}
 Reading symbols from 
 /tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
 [New process 100244]
 [New Thread 803806400 (LWP 100244)]
 Core was generated by `test_certlookup'.
 Program terminated with signal 10, Bus error.
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 (gdb) bt
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 #1  0x000802cc8c74 in free () from /lib/libc.so.7
 #2  0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear 
 (this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
 #3  0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
 #4  0x00403c11 in SSLContextStorage::~SSLContextStorage 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
 #5  0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0, 
 __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
 #6  0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0 
 regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8 
 regressionTest_SSLCertificateLookup+24)
 at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
 #7  0x00080085eff6 in start_test (t=0x60daa0 
 regressionTest_SSLCertificateLookup) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
 #8  0x00080085f404 in RegressionTest::run (atest=0x0) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
 #9  0x00402ce0 in main (argc=1, argv=0x7fffd470) at 
 /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
 (gdb)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1695) test_certlookup fails on FreeBSD


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

James Peach reassigned TS-1695:
---

Assignee: James Peach

 test_certlookup fails on FreeBSD
 

 Key: TS-1695
 URL: https://issues.apache.org/jira/browse/TS-1695
 Project: Traffic Server
  Issue Type: Bug
  Components: Portability
Reporter: Igor Galić
Assignee: James Peach
  Labels: freebsd
 Fix For: 3.3.2


 {noformat}
 Reading symbols from 
 /tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
 [New process 100244]
 [New Thread 803806400 (LWP 100244)]
 Core was generated by `test_certlookup'.
 Program terminated with signal 10, Bus error.
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 (gdb) bt
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 #1  0x000802cc8c74 in free () from /lib/libc.so.7
 #2  0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear 
 (this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
 #3  0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
 #4  0x00403c11 in SSLContextStorage::~SSLContextStorage 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
 #5  0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0, 
 __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
 #6  0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0 
 regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8 
 regressionTest_SSLCertificateLookup+24)
 at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
 #7  0x00080085eff6 in start_test (t=0x60daa0 
 regressionTest_SSLCertificateLookup) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
 #8  0x00080085f404 in RegressionTest::run (atest=0x0) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
 #9  0x00402ce0 in main (argc=1, argv=0x7fffd470) at 
 /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
 (gdb)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1695) test_certlookup fails on FreeBSD


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

James Peach updated TS-1695:


Labels: freebsd  (was: )

 test_certlookup fails on FreeBSD
 

 Key: TS-1695
 URL: https://issues.apache.org/jira/browse/TS-1695
 Project: Traffic Server
  Issue Type: Bug
  Components: Portability
Reporter: Igor Galić
  Labels: freebsd

 {noformat}
 Reading symbols from 
 /tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
 [New process 100244]
 [New Thread 803806400 (LWP 100244)]
 Core was generated by `test_certlookup'.
 Program terminated with signal 10, Bus error.
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 (gdb) bt
 #0  0x000802cbc43b in ?? () from /lib/libc.so.7
 #1  0x000802cc8c74 in free () from /lib/libc.so.7
 #2  0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear 
 (this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
 #3  0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
 #4  0x00403c11 in SSLContextStorage::~SSLContextStorage 
 (this=0x80382c800, __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
 #5  0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0, 
 __in_chrg=optimized out) at 
 /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
 #6  0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0 
 regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8 
 regressionTest_SSLCertificateLookup+24)
 at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
 #7  0x00080085eff6 in start_test (t=0x60daa0 
 regressionTest_SSLCertificateLookup) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
 #8  0x00080085f404 in RegressionTest::run (atest=0x0) at 
 /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
 #9  0x00402ce0 in main (argc=1, argv=0x7fffd470) at 
 /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
 (gdb)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1697) Add basic authentication for parent proxy


[ 
https://issues.apache.org/jira/browse/TS-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606623#comment-13606623
 ] 

James Peach commented on TS-1697:
-

Moving out to sometime until we have a contributor to work on this.

 Add basic authentication for parent proxy
 -

 Key: TS-1697
 URL: https://issues.apache.org/jira/browse/TS-1697
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, Security
Reporter: ilya stromberg
 Fix For: sometime


 We should add the basic access authentication method for parent proxy. 
 Without this feature we can use only open parent proxy or ip-based 
 authentication method, but we can have dynamic ip-adrees.
 The basic authentication is trivial. Description can be found here:
 http://en.wikipedia.org/wiki/Basic_access_authentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1697) Add basic authentication for parent proxy


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

James Peach updated TS-1697:


Component/s: Security
 Core

 Add basic authentication for parent proxy
 -

 Key: TS-1697
 URL: https://issues.apache.org/jira/browse/TS-1697
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, Security
Reporter: ilya stromberg

 We should add the basic access authentication method for parent proxy. 
 Without this feature we can use only open parent proxy or ip-based 
 authentication method, but we can have dynamic ip-adrees.
 The basic authentication is trivial. Description can be found here:
 http://en.wikipedia.org/wiki/Basic_access_authentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1697) Add basic authentication for parent proxy


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

James Peach updated TS-1697:


Fix Version/s: sometime

 Add basic authentication for parent proxy
 -

 Key: TS-1697
 URL: https://issues.apache.org/jira/browse/TS-1697
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, Security
Reporter: ilya stromberg
 Fix For: sometime


 We should add the basic access authentication method for parent proxy. 
 Without this feature we can use only open parent proxy or ip-based 
 authentication method, but we can have dynamic ip-adrees.
 The basic authentication is trivial. Description can be found here:
 http://en.wikipedia.org/wiki/Basic_access_authentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1685) configure --enable-micro doesn't build


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

James Peach updated TS-1685:


Fix Version/s: 3.5.0

 configure --enable-micro doesn't build
 --

 Key: TS-1685
 URL: https://issues.apache.org/jira/browse/TS-1685
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
 Fix For: 3.5.0


 The --enable-micro build configuration doesn't build. We should remove this 
 and any dependent compilation options.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1685) configure --enable-micro doesn't build


[ 
https://issues.apache.org/jira/browse/TS-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606624#comment-13606624
 ] 

James Peach commented on TS-1685:
-

Moving out to 3.5 until we have a contributor to work on this.

 configure --enable-micro doesn't build
 --

 Key: TS-1685
 URL: https://issues.apache.org/jira/browse/TS-1685
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
 Fix For: 3.5.0


 The --enable-micro build configuration doesn't build. We should remove this 
 and any dependent compilation options.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1593) replace hash_map with unordered_map in logstats


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

James Peach updated TS-1593:


Fix Version/s: 3.3.2

 replace hash_map with unordered_map in logstats
 ---

 Key: TS-1593
 URL: https://issues.apache.org/jira/browse/TS-1593
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Affects Versions: 3.3.0
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.2


 C++11 has a standard hash container, std::unordered_map, so in C++11 mode we 
 should replace the non-standard hash_map with unordered_map.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1593) replace hash_map with unordered_map in logstats


[ 
https://issues.apache.org/jira/browse/TS-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606626#comment-13606626
 ] 

James Peach commented on TS-1593:
-

Somewhere, I do have a patch that needs rebasing onto trunk.

 replace hash_map with unordered_map in logstats
 ---

 Key: TS-1593
 URL: https://issues.apache.org/jira/browse/TS-1593
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Affects Versions: 3.3.0
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.3.2


 C++11 has a standard hash container, std::unordered_map, so in C++11 mode we 
 should replace the non-standard hash_map with unordered_map.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1605) crash at mime_parse_int64


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

James Peach updated TS-1605:


Labels: crash  (was: )

 crash at mime_parse_int64
 -

 Key: TS-1605
 URL: https://issues.apache.org/jira/browse/TS-1605
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, MIME
Reporter: Bin Chen
  Labels: crash

 {code}
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 #1  0x0060d7a6 in mime_field_value_get_int64 (field=0x2af6853bfdd0) 
 at MIME.cc:1694
 #2  0x0057d41c in MIMEHdr::value_get_int64 (this=0x2af6853bf5c8, 
 name=0x2db7388 Age, name_length=3)
 at ../../proxy/hdrs/MIME.h:1217
 #3  0x005a9230 in MIMEHdr::get_age (this=0x2af6853bf5c8) at 
 ../../proxy/hdrs/MIME.h:1356
 #4  0x005aac0b in HttpTransactHeaders::calculate_document_age 
 (request_time=1353920547, response_time=1353920547, 
 base_response=0x2af6853bf5c8, base_response_date=1352509636, 
 now=1354258269) at HttpTransactHeaders.cc:400
 #5  0x00581d73 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2af5f0a057c0, 
 client_request=0x2af5f0a05780, http_config_params=0x2af6005fda30) at 
 HttpTransactCache.cc:221
 #6  0x00692c34 in CacheVC::openReadStartHead (this=0x2af5f0a056c0, 
 event=3900, e=0x0) at CacheRead.cc:1019
 #7  0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0, 
 event=3900, data=0x0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #8  0x006717e2 in CacheVC::handleReadDone (this=0x2af5f0a056c0, 
 event=3900, e=0x2af5f0a05840) at Cache.cc:1952
 #9  0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0, 
 event=3900, data=0x2af5f0a05840)
 at ../iocore/eventsystem/I_Continuation.h:146
 #10 0x006761cc in AIOCallbackInternal::io_complete 
 (this=0x2af5f0a05840, event=1, data=0x2af79c001420)
 at ../../iocore/aio/P_AIO.h:80
 #11 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a05840, 
 event=1, data=0x2af79c001420)
 at ../iocore/eventsystem/I_Continuation.h:146
 #12 0x006d99b8 in EThread::process_event (this=0x2af4f84e6010, 
 e=0x2af79c001420, calling_code=1)
 at UnixEThread.cc:189
 #13 0x006d9b86 in EThread::execute (this=0x2af4f84e6010) at 
 UnixEThread.cc:240
 #14 0x006d89e7 in spawn_thread_internal (a=0x2af4fc603b00) at 
 Thread.cc:88
 #15 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
 #16 0x0034bf8e570d in clone () from /lib64/libc.so.6
 (gdb) f 0
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
 (gdb) l
 3071bool negative;
 3072  
 3073if (!buf || (buf == end))
 3074  return 0;
 3075  
 3076if (is_digit(*buf))   // fast case
 3077  {
 3078num = *buf++ - '0';
 3079while ((buf != end)  is_digit(*buf))
 3080  num = (num * 10) + (*buf++ - '0');
 (gdb) p buf
 $1 = 0x3fb Address 0x3fb out of bounds
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1605) crash at mime_parse_int64


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

James Peach updated TS-1605:


Fix Version/s: sometime

 crash at mime_parse_int64
 -

 Key: TS-1605
 URL: https://issues.apache.org/jira/browse/TS-1605
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, MIME
Reporter: Bin Chen
  Labels: crash
 Fix For: sometime


 {code}
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 #1  0x0060d7a6 in mime_field_value_get_int64 (field=0x2af6853bfdd0) 
 at MIME.cc:1694
 #2  0x0057d41c in MIMEHdr::value_get_int64 (this=0x2af6853bf5c8, 
 name=0x2db7388 Age, name_length=3)
 at ../../proxy/hdrs/MIME.h:1217
 #3  0x005a9230 in MIMEHdr::get_age (this=0x2af6853bf5c8) at 
 ../../proxy/hdrs/MIME.h:1356
 #4  0x005aac0b in HttpTransactHeaders::calculate_document_age 
 (request_time=1353920547, response_time=1353920547, 
 base_response=0x2af6853bf5c8, base_response_date=1352509636, 
 now=1354258269) at HttpTransactHeaders.cc:400
 #5  0x00581d73 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2af5f0a057c0, 
 client_request=0x2af5f0a05780, http_config_params=0x2af6005fda30) at 
 HttpTransactCache.cc:221
 #6  0x00692c34 in CacheVC::openReadStartHead (this=0x2af5f0a056c0, 
 event=3900, e=0x0) at CacheRead.cc:1019
 #7  0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0, 
 event=3900, data=0x0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #8  0x006717e2 in CacheVC::handleReadDone (this=0x2af5f0a056c0, 
 event=3900, e=0x2af5f0a05840) at Cache.cc:1952
 #9  0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0, 
 event=3900, data=0x2af5f0a05840)
 at ../iocore/eventsystem/I_Continuation.h:146
 #10 0x006761cc in AIOCallbackInternal::io_complete 
 (this=0x2af5f0a05840, event=1, data=0x2af79c001420)
 at ../../iocore/aio/P_AIO.h:80
 #11 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a05840, 
 event=1, data=0x2af79c001420)
 at ../iocore/eventsystem/I_Continuation.h:146
 #12 0x006d99b8 in EThread::process_event (this=0x2af4f84e6010, 
 e=0x2af79c001420, calling_code=1)
 at UnixEThread.cc:189
 #13 0x006d9b86 in EThread::execute (this=0x2af4f84e6010) at 
 UnixEThread.cc:240
 #14 0x006d89e7 in spawn_thread_internal (a=0x2af4fc603b00) at 
 Thread.cc:88
 #15 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
 #16 0x0034bf8e570d in clone () from /lib64/libc.so.6
 (gdb) f 0
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
 (gdb) l
 3071bool negative;
 3072  
 3073if (!buf || (buf == end))
 3074  return 0;
 3075  
 3076if (is_digit(*buf))   // fast case
 3077  {
 3078num = *buf++ - '0';
 3079while ((buf != end)  is_digit(*buf))
 3080  num = (num * 10) + (*buf++ - '0');
 (gdb) p buf
 $1 = 0x3fb Address 0x3fb out of bounds
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1605) crash at mime_parse_int64


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

James Peach reassigned TS-1605:
---

Assignee: Bin Chen

Bin Chen, is there any chance of a fix here? Is this reproducible?

 crash at mime_parse_int64
 -

 Key: TS-1605
 URL: https://issues.apache.org/jira/browse/TS-1605
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, MIME
Reporter: Bin Chen
Assignee: Bin Chen
  Labels: crash
 Fix For: sometime


 {code}
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 #1  0x0060d7a6 in mime_field_value_get_int64 (field=0x2af6853bfdd0) 
 at MIME.cc:1694
 #2  0x0057d41c in MIMEHdr::value_get_int64 (this=0x2af6853bf5c8, 
 name=0x2db7388 Age, name_length=3)
 at ../../proxy/hdrs/MIME.h:1217
 #3  0x005a9230 in MIMEHdr::get_age (this=0x2af6853bf5c8) at 
 ../../proxy/hdrs/MIME.h:1356
 #4  0x005aac0b in HttpTransactHeaders::calculate_document_age 
 (request_time=1353920547, response_time=1353920547, 
 base_response=0x2af6853bf5c8, base_response_date=1352509636, 
 now=1354258269) at HttpTransactHeaders.cc:400
 #5  0x00581d73 in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2af5f0a057c0, 
 client_request=0x2af5f0a05780, http_config_params=0x2af6005fda30) at 
 HttpTransactCache.cc:221
 #6  0x00692c34 in CacheVC::openReadStartHead (this=0x2af5f0a056c0, 
 event=3900, e=0x0) at CacheRead.cc:1019
 #7  0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0, 
 event=3900, data=0x0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #8  0x006717e2 in CacheVC::handleReadDone (this=0x2af5f0a056c0, 
 event=3900, e=0x2af5f0a05840) at Cache.cc:1952
 #9  0x004e6fae in Continuation::handleEvent (this=0x2af5f0a056c0, 
 event=3900, data=0x2af5f0a05840)
 at ../iocore/eventsystem/I_Continuation.h:146
 #10 0x006761cc in AIOCallbackInternal::io_complete 
 (this=0x2af5f0a05840, event=1, data=0x2af79c001420)
 at ../../iocore/aio/P_AIO.h:80
 #11 0x004e6fae in Continuation::handleEvent (this=0x2af5f0a05840, 
 event=1, data=0x2af79c001420)
 at ../iocore/eventsystem/I_Continuation.h:146
 #12 0x006d99b8 in EThread::process_event (this=0x2af4f84e6010, 
 e=0x2af79c001420, calling_code=1)
 at UnixEThread.cc:189
 #13 0x006d9b86 in EThread::execute (this=0x2af4f84e6010) at 
 UnixEThread.cc:240
 #14 0x006d89e7 in spawn_thread_internal (a=0x2af4fc603b00) at 
 Thread.cc:88
 #15 0x0034bfc077f1 in start_thread () from /lib64/libpthread.so.0
 #16 0x0034bf8e570d in clone () from /lib64/libc.so.6
 (gdb) f 0
 #0  0x00610f76 in mime_parse_int64 (buf=0x3fb Address 0x3fb out of 
 bounds, 
 end=0x380f74 Address 0x380f74 out of bounds) at MIME.cc:3076
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/MIME.cc:3076:106103:beg:0x610f76
 (gdb) l
 3071bool negative;
 3072  
 3073if (!buf || (buf == end))
 3074  return 0;
 3075  
 3076if (is_digit(*buf))   // fast case
 3077  {
 3078num = *buf++ - '0';
 3079while ((buf != end)  is_digit(*buf))
 3080  num = (num * 10) + (*buf++ - '0');
 (gdb) p buf
 $1 = 0x3fb Address 0x3fb out of bounds
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1665) Remove TCL dependency


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

James Peach updated TS-1665:


Fix Version/s: 3.5.0

 Remove TCL dependency
 -

 Key: TS-1665
 URL: https://issues.apache.org/jira/browse/TS-1665
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Phil Sorber
Assignee: Phil Sorber
 Fix For: 3.5.0


 Remove all references to TCL and provide suitable replacements where 
 necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-1665) Remove TCL dependency


[ 
https://issues.apache.org/jira/browse/TS-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606631#comment-13606631
 ] 

James Peach commented on TS-1665:
-

Pushed out to 3.5. Phil, if you plan to work to this earlier feel free to drag 
it back.

 Remove TCL dependency
 -

 Key: TS-1665
 URL: https://issues.apache.org/jira/browse/TS-1665
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Phil Sorber
Assignee: Phil Sorber
 Fix For: 3.5.0


 Remove all references to TCL and provide suitable replacements where 
 necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1


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

James Peach reassigned TS-1635:
---

Assignee: Zhao Yongming  (was: Alan M. Carroll)

Yongming, what's going on in this bug? If there's a real bug with a patch, can 
we commit the patch?

 url parse BUGS IN Apache Traffic Sever 3.3.1 
 -

 Key: TS-1635
 URL: https://issues.apache.org/jira/browse/TS-1635
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: evilbandon
Assignee: Zhao Yongming

 url parse BUGS IN Apache Traffic Sever 3.3.1 
 the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com
 but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1


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

James Peach updated TS-1635:


Fix Version/s: 3.3.3

 url parse BUGS IN Apache Traffic Sever 3.3.1 
 -

 Key: TS-1635
 URL: https://issues.apache.org/jira/browse/TS-1635
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: evilbandon
Assignee: Zhao Yongming
 Fix For: 3.3.3


 url parse BUGS IN Apache Traffic Sever 3.3.1 
 the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com
 but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-1602) crash at http_hdr_type_get


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

James Peach updated TS-1602:


Component/s: MIME

 crash at http_hdr_type_get
 --

 Key: TS-1602
 URL: https://issues.apache.org/jira/browse/TS-1602
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, MIME
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: taorui
 Fix For: sometime


 {code}
 Program terminated with signal 11, Segmentation fault.
 #0  0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at 
 hdrs/HTTP.h:957
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at 
 hdrs/HTTP.h:957
 #1  0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at 
 hdrs/HTTP.h:967
 #2  0x0058e6f4 in HttpTransact::HandleCacheOpenRead 
 (s=0x2ba51d5d2838) at HttpTransact.cc:2046
 #3  0x0057af93 in HttpSM::call_transact_and_set_next_state 
 (this=0x2ba51d5d27d0, 
 f=0x58e5cc HttpTransact::HandleCacheOpenRead(HttpTransact::State*)) at 
 HttpSM.cc:6425
 #4  0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0, 
 event=1102, data=0x2ba3f8d00c10)
 at HttpSM.cc:2406
 #5  0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0, 
 event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
 #6  0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0, 
 event=1102, data=0x2ba3f8d00c10)
 at ../iocore/eventsystem/I_Continuation.h:146
 #7  0x00556f02 in HttpCacheSM::state_cache_open_read 
 (this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
 at HttpCacheSM.cc:118
 #8  0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898, 
 event=1102, data=0x2ba3f8d00c10)
 at ../iocore/eventsystem/I_Continuation.h:146
 #9  0x00649779 in CacheContinuation::callback_user 
 (this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
 at ClusterCache.cc:2813
 #10 0x00648433 in CacheContinuation::remoteOpEvent 
 (this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
 at ClusterCache.cc:2345
 #11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560, 
 event=1151, data=0x2ba4d149f000)
 at ../iocore/eventsystem/I_Continuation.h:146
 #12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140, 
 d=0x2ba570cd4018, l=2776)
 at ClusterCache.cc:2088
 #13 0x00651747 in ClusterHandler::process_incoming_callouts 
 (this=0x2ba428881140, m=0x2ba3f92a3c50)
 at ClusterHandler.cc:1237
 #14 0x006598db in ClusterCalloutContinuation::CalloutHandler 
 (this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
 at ClusterHandlerBase.cc:62
 #15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0, 
 event=2, data=0x2ba314b48ef0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010, 
 e=0x2ba314b48ef0, calling_code=2)
 at UnixEThread.cc:189
 #17 0x006dbd79 in PriorityEventQueue::check_ready 
 (this=0x2ba2cf82ec40, now=135396960399086, t=0x2ba2cf72e010)
 at PQ-List.cc:141
 #18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at 
 UnixEThread.cc:258
 #19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
 #20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
 #21 0x003c084e570d in clone () from /lib64/libc.so.6
 (gdb) f 0
 #0  0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at 
 hdrs/HTTP.h:957
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
 (gdb) l
 952 
 -*/
 953   
 954   inline HTTPType
 955   http_hdr_type_get(HTTPHdrImpl *hh)
 956   {
 957 return (hh-m_polarity);
 958   }
 959   
 960   
 /*-
 961 
 -*/
 (gdb) p hh-m_polarity
 Cannot access memory at address 0x2abf98de989c
 (gdb) p *hh
 Cannot access memory at address 0x2abf98de9898
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators

[jira] [Updated] (TS-1602) crash at http_hdr_type_get


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

James Peach updated TS-1602:


Labels: crash  (was: )

 crash at http_hdr_type_get
 --

 Key: TS-1602
 URL: https://issues.apache.org/jira/browse/TS-1602
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, MIME
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: taorui
  Labels: crash
 Fix For: sometime


 {code}
 Program terminated with signal 11, Segmentation fault.
 #0  0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at 
 hdrs/HTTP.h:957
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
 Missing separate debuginfos, use: debuginfo-install 
 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64 
 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 
 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 
 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 
 ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64 
 pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
 (gdb) bt
 #0  0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at 
 hdrs/HTTP.h:957
 #1  0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at 
 hdrs/HTTP.h:967
 #2  0x0058e6f4 in HttpTransact::HandleCacheOpenRead 
 (s=0x2ba51d5d2838) at HttpTransact.cc:2046
 #3  0x0057af93 in HttpSM::call_transact_and_set_next_state 
 (this=0x2ba51d5d27d0, 
 f=0x58e5cc HttpTransact::HandleCacheOpenRead(HttpTransact::State*)) at 
 HttpSM.cc:6425
 #4  0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0, 
 event=1102, data=0x2ba3f8d00c10)
 at HttpSM.cc:2406
 #5  0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0, 
 event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
 #6  0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0, 
 event=1102, data=0x2ba3f8d00c10)
 at ../iocore/eventsystem/I_Continuation.h:146
 #7  0x00556f02 in HttpCacheSM::state_cache_open_read 
 (this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
 at HttpCacheSM.cc:118
 #8  0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898, 
 event=1102, data=0x2ba3f8d00c10)
 at ../iocore/eventsystem/I_Continuation.h:146
 #9  0x00649779 in CacheContinuation::callback_user 
 (this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
 at ClusterCache.cc:2813
 #10 0x00648433 in CacheContinuation::remoteOpEvent 
 (this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
 at ClusterCache.cc:2345
 #11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560, 
 event=1151, data=0x2ba4d149f000)
 at ../iocore/eventsystem/I_Continuation.h:146
 #12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140, 
 d=0x2ba570cd4018, l=2776)
 at ClusterCache.cc:2088
 #13 0x00651747 in ClusterHandler::process_incoming_callouts 
 (this=0x2ba428881140, m=0x2ba3f92a3c50)
 at ClusterHandler.cc:1237
 #14 0x006598db in ClusterCalloutContinuation::CalloutHandler 
 (this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
 at ClusterHandlerBase.cc:62
 #15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0, 
 event=2, data=0x2ba314b48ef0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010, 
 e=0x2ba314b48ef0, calling_code=2)
 at UnixEThread.cc:189
 #17 0x006dbd79 in PriorityEventQueue::check_ready 
 (this=0x2ba2cf82ec40, now=135396960399086, t=0x2ba2cf72e010)
 at PQ-List.cc:141
 #18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at 
 UnixEThread.cc:258
 #19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
 #20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
 #21 0x003c084e570d in clone () from /lib64/libc.so.6
 (gdb) f 0
 #0  0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at 
 hdrs/HTTP.h:957
 /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
 (gdb) l
 952 
 -*/
 953   
 954   inline HTTPType
 955   http_hdr_type_get(HTTPHdrImpl *hh)
 956   {
 957 return (hh-m_polarity);
 958   }
 959   
 960   
 /*-
 961 
 -*/
 (gdb) p hh-m_polarity
 Cannot access memory at address 0x2abf98de989c
 (gdb) p *hh
 Cannot access memory at address 0x2abf98de9898
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please

[jira] [Commented] (TS-1602) crash at http_hdr_type_get