[jira] [Commented] (TS-948) do not reload bad remap.config

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-948:
--

Please try the changes on trunk, I'm closing this for now.

 do not reload bad remap.config
 --

 Key: TS-948
 URL: https://issues.apache.org/jira/browse/TS-948
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Management
Affects Versions: 3.1.0, 3.0.1
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.1


 traffic_server will exit if exists bad rules in remap.config, whenever 
 startup or reload ( traffic_line -x ).
 If remap.config is not edited correctly, the server/cluster will crash when 
 reloading.
 It's better to pre-check the remap table and not switch to the new table if 
 remap.config is not enough correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-948) do not reload bad remap.config

2011-10-11 Thread Leif Hedstrom (Resolved) (JIRA) 

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

Leif Hedstrom resolved TS-948.
--

Resolution: Fixed

 do not reload bad remap.config
 --

 Key: TS-948
 URL: https://issues.apache.org/jira/browse/TS-948
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Management
Affects Versions: 3.1.0, 3.0.1
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.1


 traffic_server will exit if exists bad rules in remap.config, whenever 
 startup or reload ( traffic_line -x ).
 If remap.config is not edited correctly, the server/cluster will crash when 
 reloading.
 It's better to pre-check the remap table and not switch to the new table if 
 remap.config is not enough correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-917) url_mapping objects don't seem to be deleted

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-917:
--

Manjesh: I took a look at this, and I don't quite see it. First, I tried it by 
reloading the remap.config lots of times, and I see no indications of memory 
being leaked. ps and valgrind both says there's no leak.

Secondly, looking at the code, it looks like it should free it, e.g.

{code}
  forl_LL(T, iter, m_value_list)
delete iter;
  m_value_list.clear();
{code}

If I'm not mistaken, this invokes the destructor for the url_mapping. Or are 
there other places where this is missing? Perhaps something with URL regexes 
(which I didn't test)?

 url_mapping objects don't seem to be deleted
 

 Key: TS-917
 URL: https://issues.apache.org/jira/browse/TS-917
 Project: Traffic Server
  Issue Type: Bug
  Components: Remap API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.1


 In the recent changes to data structures in 
 UrlRewrite/UrlMappingPathIndex/UrlMappingContainer classes, the url_mapping 
 itself is not deleted, I think. The PathIndex, Trie objects are cleaned up, 
 but not the url_mapping.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-917) url_mapping objects don't seem to be deleted

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-917:
--

Hmmm, no, it looks like the regex maps should also free the url_mapping:

{code}
  forl_LL(RegexMapping, list_iter, mappings) {
delete list_iter-url_map;
{code}

Any thoughts? I'd like to clarify this, so we can either close it, or get some 
ideas of where exactly we're leaking.

Thanks!

 url_mapping objects don't seem to be deleted
 

 Key: TS-917
 URL: https://issues.apache.org/jira/browse/TS-917
 Project: Traffic Server
  Issue Type: Bug
  Components: Remap API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.1


 In the recent changes to data structures in 
 UrlRewrite/UrlMappingPathIndex/UrlMappingContainer classes, the url_mapping 
 itself is not deleted, I think. The PathIndex, Trie objects are cleaned up, 
 but not the url_mapping.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-917) url_mapping objects don't seem to be deleted

2011-10-11 Thread Manjesh Nilange (Commented) (JIRA) 

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

Manjesh Nilange commented on TS-917:


Leif, I think you are right. I don't think there is a leak. I was not sure if 
url_mapping objects were deleted, but I did not see this change - 
http://svn.apache.org/viewvc/trafficserver/traffic/trunk/proxy/http/remap/Trie.h?diff_format=lr1=1085816r2=1085815pathrev=1085816.

It's not intuitive or clean as it is UrlRewrite.cc/url_rewrite class that does 
the new() and the Trie class does the delete. I don't think the Trie is being 
used anywhere else, but the user would have to know that the Trie will 
automatically delete the objects it holds even though it does not create them.

As for the RegexMapping, I didn't get what you are saying. The delete line does 
delete the url_mapping object and then the RegexMapping object itself is 
deleted later in the code. So both objects are cleaned up.


 url_mapping objects don't seem to be deleted
 

 Key: TS-917
 URL: https://issues.apache.org/jira/browse/TS-917
 Project: Traffic Server
  Issue Type: Bug
  Components: Remap API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.1


 In the recent changes to data structures in 
 UrlRewrite/UrlMappingPathIndex/UrlMappingContainer classes, the url_mapping 
 itself is not deleted, I think. The PathIndex, Trie objects are cleaned up, 
 but not the url_mapping.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-917) url_mapping objects don't seem to be deleted

2011-10-11 Thread Manjesh Nilange (Resolved) (JIRA) 

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

Manjesh Nilange resolved TS-917.


Resolution: Invalid

 url_mapping objects don't seem to be deleted
 

 Key: TS-917
 URL: https://issues.apache.org/jira/browse/TS-917
 Project: Traffic Server
  Issue Type: Bug
  Components: Remap API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
 Fix For: 3.1.1


 In the recent changes to data structures in 
 UrlRewrite/UrlMappingPathIndex/UrlMappingContainer classes, the url_mapping 
 itself is not deleted, I think. The PathIndex, Trie objects are cleaned up, 
 but not the url_mapping.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode

2011-10-11 Thread Leif Hedstrom (Assigned) (JIRA) 

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

Leif Hedstrom reassigned TS-871:


Assignee: Leif Hedstrom

 Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
 ---

 Key: TS-871
 URL: https://issues.apache.org/jira/browse/TS-871
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Leif Hedstrom
 Fix For: 3.1.1

 Attachments: TS-871.diff, ats_Thttp.debug.notime.txt, 
 ats_Thttp.debug.txt, revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, 
 serf_proxy.cap, serf_revproxy.cap


 When accessing a remote subversion repository via http or https with svn 1.7, 
 it will currently timeout:
 {noformat}
 igalic@tynix ~/src/asf % svn co 
 http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
 svn: E020014: Unable to connect to a repository at URL 
 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
 svn: E020014: Unspecified error message: 504 Connection Timed Out
 1 igalic@tynix ~/src/asf %
 {noformat}
 I have started traffic_server -Thttp and captured the output, which I'm 
 attaching.
 There's also a capture from the network.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-871:
-

Attachment: TS-871.diff

Igor, can you try the attached diff (against trunk) ?

 Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
 ---

 Key: TS-871
 URL: https://issues.apache.org/jira/browse/TS-871
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
 Fix For: 3.1.1

 Attachments: TS-871.diff, ats_Thttp.debug.notime.txt, 
 ats_Thttp.debug.txt, revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, 
 serf_proxy.cap, serf_revproxy.cap


 When accessing a remote subversion repository via http or https with svn 1.7, 
 it will currently timeout:
 {noformat}
 igalic@tynix ~/src/asf % svn co 
 http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
 svn: E020014: Unable to connect to a repository at URL 
 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
 svn: E020014: Unspecified error message: 504 Connection Timed Out
 1 igalic@tynix ~/src/asf %
 {noformat}
 I have started traffic_server -Thttp and captured the output, which I'm 
 attaching.
 There's also a capture from the network.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-871:
-

Attachment: (was: TS-871.diff)

 Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
 ---

 Key: TS-871
 URL: https://issues.apache.org/jira/browse/TS-871
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Leif Hedstrom
 Fix For: 3.1.1

 Attachments: ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt, 
 revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap, 
 serf_revproxy.cap, stats.diff


 When accessing a remote subversion repository via http or https with svn 1.7, 
 it will currently timeout:
 {noformat}
 igalic@tynix ~/src/asf % svn co 
 http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
 svn: E020014: Unable to connect to a repository at URL 
 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
 svn: E020014: Unspecified error message: 504 Connection Timed Out
 1 igalic@tynix ~/src/asf %
 {noformat}
 I have started traffic_server -Thttp and captured the output, which I'm 
 attaching.
 There's also a capture from the network.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-871:
-

Attachment: TS-871.diff

Proposed changes, slightly better comments etc.

 Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
 ---

 Key: TS-871
 URL: https://issues.apache.org/jira/browse/TS-871
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Leif Hedstrom
 Fix For: 3.1.1

 Attachments: TS-871.diff, ats_Thttp.debug.notime.txt, 
 ats_Thttp.debug.txt, revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, 
 serf_proxy.cap, serf_revproxy.cap, stats.diff


 When accessing a remote subversion repository via http or https with svn 1.7, 
 it will currently timeout:
 {noformat}
 igalic@tynix ~/src/asf % svn co 
 http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
 svn: E020014: Unable to connect to a repository at URL 
 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
 svn: E020014: Unspecified error message: 504 Connection Timed Out
 1 igalic@tynix ~/src/asf %
 {noformat}
 I have started traffic_server -Thttp and captured the output, which I'm 
 attaching.
 There's also a capture from the network.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-725) Crash Report: url_host_set in 2.1.6

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-725:
--

Can someone please try to either reproduce this, or confirm that it is (or 
isn't) a problem still? Moving out to 3.1.4 for now.

 Crash Report: url_host_set in 2.1.6
 ---

 Key: TS-725
 URL: https://issues.apache.org/jira/browse/TS-725
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 2.1.6
Reporter: Zhao Yongming
  Labels: crash
 Fix For: 3.1.1


 reported by user:
 {code:none}
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/ts/bin/traffic_server - STACK TRACE:
 [0x4001c420]
 /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
 [0xf]
 /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char 
 const*, int, bool)+0x51)[0x8229631]
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/ts/bin/traffic_server - STACK TRACE:
 [0x4001c420]
 /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
 [0xf]
 /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char 
 const*, int, bool)+0x51)[0x8229631]
 /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
  (*)(HttpTransact::State*))+0xab)[0x816a8eb]
 /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
  void*)+0x321)[0x817acc1]
 /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int, 
 void*)+0x1a4)[0x8184894]
 /usr/local/ts/bin/traffic_server[0x82f880c]
 /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int, 
 Event*)+0x4ce)[0x82edffe]
 /usr/local/ts/bin/traffic_server(EThread::process_event(Event*, 
 int)+0x1ff)[0x83226bf]
 /usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
 /usr/local/ts/bin/traffic_server[0x8321abc]
 /lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
 /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
 /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
 [Mar  8 11:02:52.960] Manager {3080226496} ERROR: 
 [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
 11: Segmenta
 tion fault
 [Mar  8 11:02:52.960] Manager {3080226496} ERROR:  (last system error 2: No 
 such file or directory)
 [Mar  8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm] 
 Server Process was reset
 [Mar  8 11:02:52.961] Manager {3080226496} ERROR:  (last system error 2: No 
 such file or directory)
 [Mar  8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy] 
 Launching ts process
 [TrafficServer] using root directory '/usr/local/ts'
 [Mar  8 11:02:53.973] Manager {3080226496} NOTE: 
 [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
 [Mar  8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server 
 Process born
 [Mar  8 11:02:55.015] {1079500240} STATUS: opened 
 /usr/local/ts/var/log/trafficserver/diags.log
 [Mar  8 11:02:55.015] {1079500240} NOTE: updated diags config
 [Mar  8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
 [Mar  8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
 [Mar  8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for 
 /usr/local/ts/var/log/trafficserver/access.log.pipe
 [Mar  8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7], 
 logging_mode = 3
 [Mar  8 11:02:55.368] Server {1079500240} NOTE: traffic server running
 [Mar  8 11:02:58.584] Server {1096645520} NOTE: cache enabled
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-968:
--

Hmmm, I use log rotation all the time, and never see this. Can you give us a 
stack trace from this crash?

 During/after daily logfile roll, trafficserver seg faults (Sig 11)
 --

 Key: TS-968
 URL: https://issues.apache.org/jira/browse/TS-968
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Affects Versions: 3.0.1
 Environment: Ubuntu 10.10, 2.6.35-24-virtual
Reporter: Drew Rothstein
 Fix For: 3.1.1


 Every day at 00:00:00 after/during the log file roll, I see a segfault.  Here 
 are the past couple days:
 [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile 
 /usr/local/var/log/trafficserver/error.log was rolled to 
 /usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
 [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile 
 /usr/local/var/log/trafficserver/squid.log was rolled to 
 /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
 [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile 
 /usr/local/var/log/trafficserver/extended2.log was rolled to 
 /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/bin/traffic_server - STACK TRACE: 
 [Sep 22 00:00:17.729] Manager {140722071643936} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Sep 22 00:00:17.729] Manager {140722071643936} FATAL:  (last system error 
 104: Connection reset by peer)
 [Sep 22 00:00:17.730] Manager {140722071643936} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 [Sep 22 00:00:17.730] Manager {140722071643936} NOTE: 
 [LocalManager::processShutdown] Executing process shutdown request.
 [Sep 22 00:00:17.730] Manager {140722071643936} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 [Sep 22 00:00:17.730] Manager {140722071643936} ERROR:  (last system error 
 32: Broken pipe)
 [E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
 [Sep 22 00:00:17.786] {140131209512736} STATUS: opened 
 /usr/local/var/log/trafficserver/manager.log
 [Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
 [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: 
 [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release: 
 '2.6.35-24-virtual'
 [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: 
 [LocalManager::listenForProxy] Listening on port: 80
 [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup 
 complete
 [Sep 22 00:00:18.827] Manager {140131209512736} NOTE: 
 [LocalManager::startProxy] Launching ts process
 [TrafficServer] using root directory '/usr/local'
 [Sep 22 00:00:18.849] Manager {140131209512736} NOTE: 
 [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
 [Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm] 
 Server Process born
 [Sep 22 00:00:19.874] {47510015031936} STATUS: opened 
 /usr/local/var/log/trafficserver/diags.log
 [Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
 [Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
 [Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
 [Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7], 
 logging_mode = 3
 [Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
 [Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
 [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile 
 /usr/local/var/log/trafficserver/error.log was rolled to 
 /usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
 [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile 
 /usr/local/var/log/trafficserver/squid.log was rolled to 
 /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
 [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile 
 /usr/local/var/log/trafficserver/extended2.log was rolled to 
 /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/bin/traffic_server - STACK TRACE: 
 [Sep 23 00:00:14.668] Manager {140131209512736} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Sep 23 00:00:14.668] Manager {140131209512736} FATAL:  (last system error 
 104: Connection reset by peer)

[jira] [Commented] (TS-887) Code cleanup

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-887:
--

mohan: Can you either commit this, close it, or move it out to some later 
version if this will not be worked on now.

 Code cleanup
 

 Key: TS-887
 URL: https://issues.apache.org/jira/browse/TS-887
 Project: Traffic Server
  Issue Type: Bug
Reporter: mohan_zl
 Fix For: 3.1.1

 Attachments: code_cleanup1.patch, code_cleanup2.patch, 
 code_cleanup3.patch


 Try to nuke some unused codes, not changing current logic.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-725) Crash Report: url_host_set in 2.1.6

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-725:
-

Fix Version/s: (was: 3.1.1)
   3.1.4

 Crash Report: url_host_set in 2.1.6
 ---

 Key: TS-725
 URL: https://issues.apache.org/jira/browse/TS-725
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 2.1.6
Reporter: Zhao Yongming
  Labels: crash
 Fix For: 3.1.4


 reported by user:
 {code:none}
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/ts/bin/traffic_server - STACK TRACE:
 [0x4001c420]
 /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
 [0xf]
 /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char 
 const*, int, bool)+0x51)[0x8229631]
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/ts/bin/traffic_server - STACK TRACE:
 [0x4001c420]
 /lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
 [0xf]
 /usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char 
 const*, int, bool)+0x51)[0x8229631]
 /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
  (*)(HttpTransact::State*))+0xab)[0x816a8eb]
 /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
  void*)+0x321)[0x817acc1]
 /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int, 
 void*)+0x1a4)[0x8184894]
 /usr/local/ts/bin/traffic_server[0x82f880c]
 /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int, 
 Event*)+0x4ce)[0x82edffe]
 /usr/local/ts/bin/traffic_server(EThread::process_event(Event*, 
 int)+0x1ff)[0x83226bf]
 /usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
 /usr/local/ts/bin/traffic_server[0x8321abc]
 /lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
 /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
 /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
 [Mar  8 11:02:52.960] Manager {3080226496} ERROR: 
 [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 
 11: Segmenta
 tion fault
 [Mar  8 11:02:52.960] Manager {3080226496} ERROR:  (last system error 2: No 
 such file or directory)
 [Mar  8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm] 
 Server Process was reset
 [Mar  8 11:02:52.961] Manager {3080226496} ERROR:  (last system error 2: No 
 such file or directory)
 [Mar  8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy] 
 Launching ts process
 [TrafficServer] using root directory '/usr/local/ts'
 [Mar  8 11:02:53.973] Manager {3080226496} NOTE: 
 [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
 [Mar  8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server 
 Process born
 [Mar  8 11:02:55.015] {1079500240} STATUS: opened 
 /usr/local/ts/var/log/trafficserver/diags.log
 [Mar  8 11:02:55.015] {1079500240} NOTE: updated diags config
 [Mar  8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
 [Mar  8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
 [Mar  8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for 
 /usr/local/ts/var/log/trafficserver/access.log.pipe
 [Mar  8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7], 
 logging_mode = 3
 [Mar  8 11:02:55.368] Server {1079500240} NOTE: traffic server running
 [Mar  8 11:02:58.584] Server {1096645520} NOTE: cache enabled
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-899) ts crash

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-899:
--

Any update on this? Is anyone working on this ?

 ts crash
 

 Key: TS-899
 URL: https://issues.apache.org/jira/browse/TS-899
 Project: Traffic Server
  Issue Type: Sub-task
  Components: HTTP, MIME
Affects Versions: 3.0.1
 Environment: readhat5.5, ts-3.0.1, X86-64
Reporter: weijin
Assignee: weijin
 Fix For: 3.1.1


 If a request url is forbidden then redirected to another url, TS crash.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-891) Crash report: mime_hdr_sanity_check in mime_parser_parse during

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-891:
-

Fix Version/s: (was: 3.1.1)
   3.1.4

I'm moving this out to 3.1.4 for now. Can someone please either confirm that 
this is still a problem, and (hopefully) give some ideas how to reproduce it?

 Crash report: mime_hdr_sanity_check in mime_parser_parse during 
 

 Key: TS-891
 URL: https://issues.apache.org/jira/browse/TS-891
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.1
 Environment: v3.0.1, submit from user
Reporter: Zhao Yongming
  Labels: crash
 Fix For: 3.1.4


 no other information, place holding first.
 {code}
 zym@zym6400 ~ $ c++filt  /tmp/a 
 FATAL: MIME.cc:576: failed assert `strncasecmp(field-m_ptr_name, wks, 
 field-m_len_name) == 0`
 /usr/local/ts/bin/traffic_server - STACK TRACE:
 /usr/local/ts/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0x4003109b]
 /usr/local/ts/lib/libtsutil.so.3(ink_fatal+0x2b)[0x400310ed]
 /usr/local/ts/lib/libtsutil.so.3(_ink_assert+0xc4)[0x4002fd54]
 /usr/local/ts/bin/traffic_server(mime_hdr_sanity_check(MIMEHdrImpl*)+0x323)[0x823f5c8]
 /usr/local/ts/bin/traffic_server(mime_hdr_field_attach(MIMEHdrImpl*, 
 MIMEField*, int, MIMEField*)+0x36[0x8241e17]
 /usr/local/ts/bin/traffic_server(mime_parser_parse(MIMEParser*, HdrHeap*, 
 MIMEHdrImpl*, char const**, char const*, bool, bool)+0x2b5)[0x82442b6]
 /usr/local/ts/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*, 
 HTTPHdrImpl*, char const**, char const*, bool, bool)+0x801)[0x823ae17]
 /usr/local/ts/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*, 
 IOBufferReader*, int*, bool)+0x126)[0x82380f4]
 /usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
  void*)+0x2f0)[0x819b87c]
 /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int, 
 void*)+0x1f[0x81a0cc0]
 /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x47)[0x81154f9]
 /usr/local/ts/bin/traffic_server[0x82f644c]
 /usr/local/ts/bin/traffic_server[0x82f6e43]
 /usr/local/ts/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*, 
 EThread*)+0x17)[0x82f8c6d]
 /usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int, 
 Event*)+0x62a)[0x82f2ea4]
 /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x47)[0x81154f9]
 /usr/local/ts/bin/traffic_server(EThread::process_event(Event*, 
 int)+0x114)[0x831af5a]
 /usr/local/ts/bin/traffic_server(EThread::execute()+0x425)[0x831b529]
 /usr/local/ts/bin/traffic_server(main+0x1245)[0x813f233]
 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x40476450]
 /usr/local/ts/bin/traffic_server[0x80f60e1]
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-920) HTTP CONNECT gives bad request line

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-920:
-

Fix Version/s: (was: 3.1.1)
   3.1.2

Moving this out to 3.1.2 for now.

 HTTP CONNECT gives bad request line
 ---

 Key: TS-920
 URL: https://issues.apache.org/jira/browse/TS-920
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: M. Nunberg
 Fix For: 3.1.2


 An HTTP CONNECT tunnel request such as:
 CONNECT foo.com:443 HTTP/1.1
 
 is translated into:
 CONNECT https://foo.com:443/ HTTP/1.1
 
 and is sent as such to a parent proxy when ATS is configured to forward 
 requests to parent proxy. This can break the parent proxy in some (all?) 
 cases, since the semi-standard for CONNECT is a host specification, not a URI.
 In practice, for most applications, this issue is quite rare since it is 
 often pointless to forward CONNECT requests, unless the parent proxy does 
 some special handling or man-in-the-middle operations etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TS-922) TSVIONTodoGet() has bug!

2011-10-11 Thread Leif Hedstrom (Resolved) (JIRA) 

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

Leif Hedstrom resolved TS-922.
--

Resolution: Invalid

I'm closing this as invalid, I think William's comment is accurate, it's as 
expected. Please reopen if you disagree.

 TSVIONTodoGet() has bug!
 

 Key: TS-922
 URL: https://issues.apache.org/jira/browse/TS-922
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.1
 Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0, Web 
 Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 
 500G
Reporter: taoyunxing
  Labels: TS_API_bug
 Fix For: 3.1.1

   Original Estimate: 672h
  Remaining Estimate: 672h

 when I use null-transform plugin and print some debug info, I find the 
 TSVIONTodoGet() return a huge member, I consider it maybe has a bug !
 The details shows below:
 code in null-transform.c:
   TSVIO input_vio;
   int64_t towrite = 0;
   int64_t avail = 0;
   towrite = TSVIONTodoGet(input_vio);
   TSDebug(null-transform, \ttoWrite is % PRId64 , towrite);
   if (towrite  0) {
 /* The amount of data left to read needs to be truncated by
  * the amount of data actually in the read buffer.
  */
 avail = TSIOBufferReaderAvail(TSVIOReaderGet(input_vio));
 TSDebug(null-transform, \tavail is % PRId64 , avail);
 #if MDSN_LOG
   if (log) {
   TSTextLogObjectWrite(log, handle_transform() with data to 
 write  length: % PRId64 , IOBufferReader available data length: % PRId64 
 , towrite, avail);}
 #endif
 log info:
 20110818.13h51m11s handle_transform() with data to write  length: 
 9223372036854775807, IOBufferReader available data length: 1388
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-952:
--

Hmmm, i think this is by design at this point :-/. I'm going to move this out 
to v3.3.0 for now, if someone else wish to work on this (I think it'd require 
some major re-factoring of the code), please feel to re-prioritize.

 when turn off config.proxy.hostdb, ts just reponse a 502 page.
 --

 Key: TS-952
 URL: https://issues.apache.org/jira/browse/TS-952
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS, HTTP
Affects Versions: 3.1.0
 Environment: all.
Reporter: weijin
 Fix For: 3.3.0


 If turn config.proxy.hostdb off, ts does not do the dns query but just return 
 a 502 page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-952) when turn off config.proxy.hostdb, ts just reponse a 502 page.

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-952:
-

Fix Version/s: (was: 3.1.1)
   3.3.0

 when turn off config.proxy.hostdb, ts just reponse a 502 page.
 --

 Key: TS-952
 URL: https://issues.apache.org/jira/browse/TS-952
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS, HTTP
Affects Versions: 3.1.0
 Environment: all.
Reporter: weijin
 Fix For: 3.3.0


 If turn config.proxy.hostdb off, ts does not do the dns query but just return 
 a 502 page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-942) Assert in HttpTransact::HandleCacheOpenReadMiss

2011-10-11 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-942:
-

Fix Version/s: (was: 3.1.1)
   3.1.2
 Assignee: Leif Hedstrom

 Assert in HttpTransact::HandleCacheOpenReadMiss
 ---

 Key: TS-942
 URL: https://issues.apache.org/jira/browse/TS-942
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.1.1
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.2


 I'm seeing a crasher (see below), and it happens in code like this:
 {code}
 if (s-current.server-ip == 0) {
   ink_release_assert(s-current.request_to == PARENT_PROXY ||
   s-http_config_param-no_dns_forward_to_parent != 0);
   if (s-current.request_to == PARENT_PROXY) {
 {code}
 What happens is that .server-ip is indeed 0, but current.request_to is != 
 PARENT_PROXY (it is instead ORIGIN_SERVER). I've not seen this before, and it 
 reproduces rarely, so wondering if it could be IPv6 related.
 Crasher:
 {code}
 (gdb) bt
 #0  0x003f2de327f5 in raise (sig=6) at 
 ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 #1  0x003f2de33fd5 in abort () at abort.c:92
 #2  0x006407a1 in ink_die_die_die (return_code=value optimized out, 
 message_format=value optimized out, ap=0x2b0756137600) at ink_error.cc:43
 #3  ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *) 
 (return_code=value optimized out, message_format=value optimized out, 
 ap=0x2b0756137600) at ink_error.cc:65
 #4  0x006408d6 in ink_fatal (return_code=value optimized out, 
 message_format=value optimized out) at ink_error.cc:73
 #5  0x0063f761 in _ink_assert (a=0x668400 s-current.request_to == 
 PARENT_PROXY || s-http_config_param-no_dns_forward_to_parent != 0, 
 f=value optimized out, l=2952) at ink_assert.cc:44
 #6  0x00516d5c in HttpTransact::HandleCacheOpenReadMiss 
 (s=0x2b0763638018) at HttpTransact.cc:2952
 #7  0x004f08e2 in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0763637fb0, f=value optimized out) at HttpSM.cc:6339
 #8  0x004fffda in HttpSM::handle_api_return (this=0x2b0763637fb0) at 
 HttpSM.cc:1520
 #9  0x004f2d42 in HttpSM::state_hostdb_lookup (this=value optimized 
 out, event=value optimized out, data=value optimized out) at 
 HttpSM.cc:2064
 #10 0x00503de0 in HttpSM::main_handler (this=0x2b0763637fb0, 
 event=500, data=0x2b0760231860) at HttpSM.cc:2454
 #11 0x0058d07b in handleEvent (cont=0x2b0763637fb0, 
 ar=0x2b0760231860) at ../../iocore/eventsystem/I_Continuation.h:146
 #12 reply_to_cont (cont=0x2b0763637fb0, ar=0x2b0760231860) at HostDB.cc:552
 #13 0x0058e939 in HostDBContinuation::dnsEvent (this=value optimized 
 out, event=value optimized out, e=value optimized out) at HostDB.cc:1504
 #14 0x0059d281 in handleEvent (this=0x2a1c340, event=value optimized 
 out, e=value optimized out) at 
 ../../iocore/eventsystem/I_Continuation.h:146
 #15 DNSEntry::postEvent (this=0x2a1c340, event=value optimized out, 
 e=value optimized out) at DNS.cc:1265
 #16 0x00638204 in handleEvent (this=0x2b0755e36010, e=0x2a61090, 
 calling_code=1) at I_Continuation.h:146
 #17 EThread::process_event (this=0x2b0755e36010, e=0x2a61090, calling_code=1) 
 at UnixEThread.cc:140
 #18 0x00638c7b in EThread::execute (this=0x2b0755e36010) at 
 UnixEThread.cc:189
 #19 0x00637052 in spawn_thread_internal (a=0x1b206b0) at Thread.cc:88
 #20 0x003f2e6068e0 in start_thread (arg=0x2b0756138710) at 
 pthread_create.c:297
 #21 0x003f2dee0c9d in clone () at 
 ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 #22 0x in ?? ()
 (gdb) frame 6
 #6  0x00516d5c in HttpTransact::HandleCacheOpenReadMiss 
 (s=0x2b0763638018) at HttpTransact.cc:2952
 2952s-http_config_param-no_dns_forward_to_parent != 0);
 (gdb) print s-current.request_to
 $1 = ORIGIN_SERVER
 (gdb) print s-current.server-ip
 $2 = 0
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-942) Assert in HttpTransact::HandleCacheOpenReadMiss

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-942:
--

Haven't seen this in a while I think, so moving out for now.

 Assert in HttpTransact::HandleCacheOpenReadMiss
 ---

 Key: TS-942
 URL: https://issues.apache.org/jira/browse/TS-942
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.1.1
Reporter: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.2


 I'm seeing a crasher (see below), and it happens in code like this:
 {code}
 if (s-current.server-ip == 0) {
   ink_release_assert(s-current.request_to == PARENT_PROXY ||
   s-http_config_param-no_dns_forward_to_parent != 0);
   if (s-current.request_to == PARENT_PROXY) {
 {code}
 What happens is that .server-ip is indeed 0, but current.request_to is != 
 PARENT_PROXY (it is instead ORIGIN_SERVER). I've not seen this before, and it 
 reproduces rarely, so wondering if it could be IPv6 related.
 Crasher:
 {code}
 (gdb) bt
 #0  0x003f2de327f5 in raise (sig=6) at 
 ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 #1  0x003f2de33fd5 in abort () at abort.c:92
 #2  0x006407a1 in ink_die_die_die (return_code=value optimized out, 
 message_format=value optimized out, ap=0x2b0756137600) at ink_error.cc:43
 #3  ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *) 
 (return_code=value optimized out, message_format=value optimized out, 
 ap=0x2b0756137600) at ink_error.cc:65
 #4  0x006408d6 in ink_fatal (return_code=value optimized out, 
 message_format=value optimized out) at ink_error.cc:73
 #5  0x0063f761 in _ink_assert (a=0x668400 s-current.request_to == 
 PARENT_PROXY || s-http_config_param-no_dns_forward_to_parent != 0, 
 f=value optimized out, l=2952) at ink_assert.cc:44
 #6  0x00516d5c in HttpTransact::HandleCacheOpenReadMiss 
 (s=0x2b0763638018) at HttpTransact.cc:2952
 #7  0x004f08e2 in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0763637fb0, f=value optimized out) at HttpSM.cc:6339
 #8  0x004fffda in HttpSM::handle_api_return (this=0x2b0763637fb0) at 
 HttpSM.cc:1520
 #9  0x004f2d42 in HttpSM::state_hostdb_lookup (this=value optimized 
 out, event=value optimized out, data=value optimized out) at 
 HttpSM.cc:2064
 #10 0x00503de0 in HttpSM::main_handler (this=0x2b0763637fb0, 
 event=500, data=0x2b0760231860) at HttpSM.cc:2454
 #11 0x0058d07b in handleEvent (cont=0x2b0763637fb0, 
 ar=0x2b0760231860) at ../../iocore/eventsystem/I_Continuation.h:146
 #12 reply_to_cont (cont=0x2b0763637fb0, ar=0x2b0760231860) at HostDB.cc:552
 #13 0x0058e939 in HostDBContinuation::dnsEvent (this=value optimized 
 out, event=value optimized out, e=value optimized out) at HostDB.cc:1504
 #14 0x0059d281 in handleEvent (this=0x2a1c340, event=value optimized 
 out, e=value optimized out) at 
 ../../iocore/eventsystem/I_Continuation.h:146
 #15 DNSEntry::postEvent (this=0x2a1c340, event=value optimized out, 
 e=value optimized out) at DNS.cc:1265
 #16 0x00638204 in handleEvent (this=0x2b0755e36010, e=0x2a61090, 
 calling_code=1) at I_Continuation.h:146
 #17 EThread::process_event (this=0x2b0755e36010, e=0x2a61090, calling_code=1) 
 at UnixEThread.cc:140
 #18 0x00638c7b in EThread::execute (this=0x2b0755e36010) at 
 UnixEThread.cc:189
 #19 0x00637052 in spawn_thread_internal (a=0x1b206b0) at Thread.cc:88
 #20 0x003f2e6068e0 in start_thread (arg=0x2b0756138710) at 
 pthread_create.c:297
 #21 0x003f2dee0c9d in clone () at 
 ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 #22 0x in ?? ()
 (gdb) frame 6
 #6  0x00516d5c in HttpTransact::HandleCacheOpenReadMiss 
 (s=0x2b0763638018) at HttpTransact.cc:2952
 2952s-http_config_param-no_dns_forward_to_parent != 0);
 (gdb) print s-current.request_to
 $1 = ORIGIN_SERVER
 (gdb) print s-current.server-ip
 $2 = 0
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-912) TSFetchURL - poor performance

2011-10-11 Thread Manjesh Nilange (Commented) (JIRA) 

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

Manjesh Nilange commented on TS-912:


Here's a simpler version of the situation.

http://pastebin.com/8CkNJKmS


 TSFetchURL - poor performance
 -

 Key: TS-912
 URL: https://issues.apache.org/jira/browse/TS-912
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
 Environment: Linux
Reporter: Naveen
  Labels: api, perfomance, ts
 Fix For: 3.1.1


 Running a Apache benchmark with a simple plugin that just does TSFetchURL 
 gives a ~13ms response time. The Fetch was on a localhost. All the plugin 
 does is just sends an hello world response to the client. 
 http://pastebin.com/1uEvuZqk
 Removing the TSFetchURL from the picture gives a response time of 1ms.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-948) do not reload bad remap.config

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

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

Conan Wang commented on TS-948:
---

My test: 
1. duplicate remap rule and adding non-exist remap plugin now will not crash 
running ATS. I can see WARNING: failed to reload remap.config, not replacing! 
in traffic.out.

2. though bad remap.config is not reloaded, seem TSRemapDeleteInstance 
(TSfree ihandle) of my remap plugin is called according to my debug log. 
However, my remap plugin work well like before, that is, I can still retrieve 
the stored variable in ihandle. I don't know whether there is potential problem.

3. return TS_ERROR in TSRemapNewInstance still crash.
{code}
Server {0x1079f6000} ERROR: Failed to create new instance for plugin 
/Users/conan/box/ts-trunk/libexec/trafficserver/add_header.so (non-zero 
retval)... bailing out
FATAL: UnixUDPNet.cc:295: failed assert `event != NULL`
/Users/conan/box/ts-trunk/bin/traffic_server - STACK TRACE: 
0   libtsutil.3.dylib   0x000102fb05ab ink_fatal_va + 283
1   libtsutil.3.dylib   0x000102fb08b4 ink_fatal + 356
2   libtsutil.3.dylib   0x000102fadcff _ink_assert + 271
3   traffic_server  0x000102684f45 
_ZN19UDPReadContinuationD1Ev + 85
4   traffic_server  0x0001026850c6 
_ZN14ClassAllocatorI19UDPReadContinuationE4$_44D1Ev + 24
5   traffic_server  0x00010268f59d 
_ZN14ClassAllocatorI19UDPReadContinuationED1Ev + 37
6   traffic_server  0x0001026850eb __tcf_3 + 27
7   libsystem_c.dylib   0x7fff872217c8 __cxa_finalize + 274
8   libsystem_c.dylib   0x7fff87221652 exit + 18
9   traffic_server  0x0001024aca9c 
_ZN10UrlRewrite17load_remap_pluginEPPciP11url_mappingS0_iiPi + 8284
10  traffic_server  0x0001024b5473 
_ZN10UrlRewrite10BuildTableEv + 12757
11  traffic_server  0x0001024b8dc5 
_ZN10UrlRewriteC1EPKc + 2165
12  traffic_server  0x0001023b450e 
_Z16reloadUrlRewritev + 350
13  traffic_server  0x0001023b5296 
_ZN21UR_UpdateContinuation19file_update_handlerEiPv + 24
14  traffic_server  0x0001023d7434 
_ZN12Continuation11handleEventEiPv + 148
15  traffic_server  0x0001026a787a 
_ZN7EThread13process_eventEP5Eventi + 418
16  traffic_server  0x0001026a6c85 
_ZN7EThread7executeEv + 191
17  traffic_server  0x0001026a6174 
_ZL21spawn_thread_internalPv + 132
18  libsystem_c.dylib   0x7fff8722e8bf _pthread_start + 335
19  libsystem_c.dylib   0x7fff87231b75 thread_start + 13
{code}

 do not reload bad remap.config
 --

 Key: TS-948
 URL: https://issues.apache.org/jira/browse/TS-948
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Management
Affects Versions: 3.1.0, 3.0.1
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.1


 traffic_server will exit if exists bad rules in remap.config, whenever 
 startup or reload ( traffic_line -x ).
 If remap.config is not edited correctly, the server/cluster will crash when 
 reloading.
 It's better to pre-check the remap table and not switch to the new table if 
 remap.config is not enough correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TS-948) do not reload bad remap.config

2011-10-11 Thread Leif Hedstrom (Commented) (JIRA) 

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

Leif Hedstrom commented on TS-948:
--

On 2, yeas, as expected. It still goes through all instantiatiobs, but 
unwinds on failure . Since this is no different for your plugin whether it 
succeeds or not, it shouldn't matter. You still have to deal with proper 
uninstantiation on every reload.

On 3, bah, missed that special case, nice catch. I'll look at it tomorrow.

 do not reload bad remap.config
 --

 Key: TS-948
 URL: https://issues.apache.org/jira/browse/TS-948
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Management
Affects Versions: 3.1.0, 3.0.1
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.1


 traffic_server will exit if exists bad rules in remap.config, whenever 
 startup or reload ( traffic_line -x ).
 If remap.config is not edited correctly, the server/cluster will crash when 
 reloading.
 It's better to pre-check the remap table and not switch to the new table if 
 remap.config is not enough correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (TS-948) do not reload bad remap.config

2011-10-11 Thread Leif Hedstrom (Reopened) (JIRA) 

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

Leif Hedstrom reopened TS-948:
--


Reopen to deal with plugins failing to reinstatiate,

 do not reload bad remap.config
 --

 Key: TS-948
 URL: https://issues.apache.org/jira/browse/TS-948
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Management
Affects Versions: 3.1.0, 3.0.1
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.1


 traffic_server will exit if exists bad rules in remap.config, whenever 
 startup or reload ( traffic_line -x ).
 If remap.config is not edited correctly, the server/cluster will crash when 
 reloading.
 It's better to pre-check the remap table and not switch to the new table if 
 remap.config is not enough correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira