[jira] [Closed] (TS-1051) Updating logs_xml.config requires full restart
[
https://issues.apache.org/jira/browse/TS-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-1051.
-
Resolution: Not A Problem
Fix Version/s: (was: 3.3.0)
sometime
reopen if it still valid
Updating logs_xml.config requires full restart
--
Key: TS-1051
URL: https://issues.apache.org/jira/browse/TS-1051
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.2
Reporter: Billy Vierra
Assignee: Zhao Yongming
Fix For: sometime
Using SVN Rev: 1214051
URL: http://svn.apache.org/repos/asf/trafficserver/traffic/trunk
upon adding a new LogObject and doing traffic_line -x you get the following
in traffic.out
[Dec 14 12:31:48.533] Manager {0x7f2f2abef700} NOTE: User has changed config
file logs_xml.config
However it does not go into effect (new log is not created). Upon full
restart: trafficserver stop, trafficserver start it will add the new log file
as expected.
Not sure if it is a bug with docs or in 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] [Closed] (TS-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)
[
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-968.
Resolution: Cannot Reproduce
close for now, reopen if it is still valid.
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
Assignee: Zhao Yongming
Fix For: 3.1.4
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)
[Sep 23 00:00:14.668] Manager {140131209512736} NOTE:
[jira] [Closed] (TS-1178) cop will kill manager server, even cop it self
[
https://issues.apache.org/jira/browse/TS-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-1178.
-
Resolution: Fixed
let's blame that Igor.
cop will kill manager server, even cop it self
Key: TS-1178
URL: https://issues.apache.org/jira/browse/TS-1178
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.4
Environment: git master on RHEL6.1 x86_64
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.4
{code}
[root@test58 trafficserver]# cat /tmp/traffic_cop.trace
1333239680. [DEBUG]: Entering init()
1333239680. [DEBUG]: Entering init_signals()
1333239680. [DEBUG]: Entering set_alarm_death()
1333239680. [DEBUG]: Leaving set_alarm_death()
1333239680. [DEBUG]: Leaving init_signals()
1333239680. [DEBUG]: Entering init_config_dir()
1333239680. [DEBUG]: Leaving init_config_dir()
1333239680. [DEBUG]: Entering init_config_file()
1333239680. [DEBUG]: Leaving init_config_file()
1333239680. [DEBUG]: Entering init_lockfiles()
1333239680. [DEBUG]: Leaving init_lockfiles()
1333239680. [DEBUG]: Entering check_lockfile()
1333239680. [unknown]: --- Cop Starting [Version: Apache Traffic Server
- traffic_cop - 3.1.4-unstable - (build # 310 on Apr 1 2012 at 00:34:30)] ---
1333239680. [DEBUG]: Leaving check_lockfile()
1333239680. [DEBUG]: Leaving init()
1333239680. [DEBUG]: Entering check()
1333239680. [DEBUG]: Entering check_no_run()
1333239680. [DEBUG]: Entering transient_error(2, 500)
1333239680. [DEBUG]: Leaving transient_error(2, 500) -- false
1333239680. [DEBUG]: Leaving check_no_run() -- 0
1333239680. [DEBUG]: Entering read_config()
1333239680. [DEBUG]: Entering build_config_table(33932704)
1333239680. [DEBUG]: Leaving build_config_table(33932704)
1333239680. [DEBUG]: Entering process_syslog_config()
1333239680. [DEBUG]: Leaving process_syslog_config()
1333239680. [DEBUG]: Leaving read_config()
1333239680. [DEBUG]: Entering check_programs()
1333239680. [DEBUG]: Entering heartbeat_manager()
1333239680. [WARNING]: (cli test) unable to retrieve manager_binary
1333239680. [WARNING]: manager heartbeat [variable] failed [1]
1333239680. [DEBUG]: Leaving heartbeat_manager() -- -1
1333239680. [DEBUG]: Entering check_memory()
1333239680. [DEBUG]: Leaving check_memory()
1333239680. [DEBUG]: Entering millisleep(1)
1333239680. [DEBUG]: Leaving millisleep(1)
1333239680. [DEBUG]: Entering check_no_run()
1333239680. [DEBUG]: Entering transient_error(2, 500)
1333239680. [DEBUG]: Leaving transient_error(2, 500) -- false
1333239680. [DEBUG]: Leaving check_no_run() -- 0
1333239680. [DEBUG]: Entering read_config()
1333239680. [DEBUG]: Entering check_programs()
1333239680. [DEBUG]: Entering heartbeat_manager()
1333239680. [DEBUG]: Entering milliseconds()
1333239680. [DEBUG]: Leaving milliseconds()
1333239680. [DEBUG]: Entering open_socket(8088, (null), (null))
1333239680. [DEBUG]: Entering transient_error(115, 500)
1333239680. [DEBUG]: Leaving transient_error(115, 500) -- false
1333239680. [DEBUG]: Leaving open_socket(8088, 127.0.0.1, (null)) -- 8
1333239680. [DEBUG]: Entering milliseconds()
1333239680. [DEBUG]: Leaving milliseconds()
1333239680. [DEBUG]: Entering milliseconds()
1333239680. [DEBUG]: Leaving milliseconds()
1333239680. [DEBUG]: Entering milliseconds()
1333239680. [DEBUG]: Leaving milliseconds()
1333239680. [WARNING]: (manager test) bad response value
1333239680. [WARNING]: manager heartbeat [variable] failed [2]
1333239680. [WARNING]: killing manager
1333239680. [DEBUG]: Entering
safe_kill(/var/run/trafficserver/manager.lock, traffic_manager, 1)
1333239680. [DEBUG]: Entering set_alarm_warn()
1333239680. [DEBUG]: Leaving set_alarm_warn()
1333239680. [DEBUG]: Entering set_alarm_death()
1333239680. [DEBUG]: Leaving set_alarm_death()
1333239680. [DEBUG]: Leaving
safe_kill(/var/run/trafficserver/manager.lock, traffic_manager, 1)
1333239680. [DEBUG]: Leaving heartbeat_manager() -- -1
1333239680. [DEBUG]: Entering check_memory()
1333239680. [DEBUG]: Leaving check_memory()
1333239680. [DEBUG]: Entering millisleep(1)
1333239680. [DEBUG]: Leaving millisleep(1)
1333239680. [DEBUG]: Entering check_no_run()
1333239680. [DEBUG]: Entering transient_error(2, 500)
1333239680. [DEBUG]: Leaving transient_error(2, 500) -- false
1333239680. [DEBUG]: Leaving check_no_run() -- 0
1333239680. [DEBUG]: Entering read_config()
1333239680. [DEBUG]:
[jira] [Closed] (TS-1151) in some strange situation, cop will crash
[
https://issues.apache.org/jira/browse/TS-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-1151.
-
Resolution: Cannot Reproduce
closed after TS-1178, reopen if it still valid.
in some strange situation, cop will crash
-
Key: TS-1151
URL: https://issues.apache.org/jira/browse/TS-1151
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.4
we get some strange crash, the manager cop may die, we are not sure what
that is, but I'd like to start one Issue here if we have other same issue.
here is the log in /var/log/messages
{code}
Mar 19 10:08:24 cache172.cn77 kernel:: [1553138.961401] [ET_NET 2][17949]:
segfault at 2aadf1387937 ip 003c5bc7bdbe sp 410f3188 error 4 in
libc-2.5.so[3c5bc0+14d000]
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: cop received child status
signal [17935 2816]
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: traffic_manager not
running, making sure traffic_server is dead
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: spawning traffic_manager
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: --- Manager
Starting ---
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:08:46 cache172.cn77 traffic_cop[17933]: (cli test) unable to
retrieve manager_binary
Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: --- Server Starting
---
Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar 9 2012
at 09:56:00)
Mar 19 10:09:00 cache172.cn77 traffic_server[2789]: {0x2b5a8ef03970} STATUS:
opened /var/log/trafficserver/diags.log
Mar 19 10:14:02 cache172.cn77 kernel:: [1553476.364204] [ET_NET 0][2789]:
segfault at 2aab1fa99ce3 ip 003c5bc7bdbe sp 7fff39743fa8 error 4 in
libc-2.5.so[3c5bc0+14d000]
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
(last system error 32: Broken pipe)
{code}
here is the message in traffic.out
{code}
Mar 19 10:11:06 cache162.cn77 kernel:: [2510081.212455] [ET_NET 3][319]:
segfault at 2aaae6e986bc ip 003f7f27bdbe sp 40be2188 error 4 in
libc-2.5.so[3f7f20+14d000]
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: cop received child status
signal [305 2816]
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: traffic_manager not running,
making sure traffic_server is dead
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: spawning traffic_manager
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: --- Manager
Starting ---
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:11:23 cache162.cn77 traffic_cop[303]: (cli test) unable to retrieve
manager_binary
Mar 19 10:11:39 cache162.cn77
[jira] [Closed] (TS-1112) traffic_cop may crash at free()
[ https://issues.apache.org/jira/browse/TS-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming closed TS-1112. - Resolution: Cannot Reproduce reopen if it still valid traffic_cop may crash at free() --- Key: TS-1112 URL: https://issues.apache.org/jira/browse/TS-1112 Project: Traffic Server Issue Type: Bug Environment: v3.0.x Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 traffic_cop may crash, at memory free, that will leave the manager server alone, or may die with the manager too, leave a system without service. -- 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] [Closed] (TS-1060) fail assert at CacheVC::handleReadDone
[
https://issues.apache.org/jira/browse/TS-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-1060.
-
Resolution: Fixed
I think most of the cache issues is fixed already, reopen if it still valid
fail assert at CacheVC::handleReadDone
--
Key: TS-1060
URL: https://issues.apache.org/jira/browse/TS-1060
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 3.0.1
Environment: v3.0.x, with some patch from taobao
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Labels: crash
Fix For: 3.1.4
{code}
#0 0x003f96032a45 in raise () from /lib64/libc.so.6
#1 0x003f96034225 in abort () from /lib64/libc.so.6
#2 0x2b0dea6f6394 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b0dea6f6466 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b0deb9ed240 Cache.cc:1959: failed assert `((Doc *)
buf-data())-magic == DOC_MAGIC`, ap=0x2b0deb9ed140) at ink_error.cc:65
#4 0x2b0dea6f6531 in ink_fatal (return_code=1,
message_format=0x2b0deb9ed240 Cache.cc:1959: failed assert `((Doc *)
buf-data())-magic == DOC_MAGIC`) at ink_error.cc:73
#5 0x2b0dea6f4ece in _ink_assert (a=0x773770 ((Doc *)
buf-data())-magic == DOC_MAGIC, f=0x7726be Cache.cc, l=1959) at
ink_assert.cc:44
#6 0x0069429a in CacheVC::handleReadDone (this=0x3d51710,
event=3900, e=0x0) at Cache.cc:1959
#7 0x004e02fa in Continuation::handleEvent (this=0x3d51710,
event=3900, data=0x0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x006b7715 in Cache::open_read (this=0x3aeaf00,
cont=0x2b0e20737fa8, key=0x2b0deb9ed9c0, request=0x2b0e207365d0,
params=0x2b0e20735e08,
type=CACHE_FRAG_TYPE_HTTP,
hostname=0x2b0e300458cb
img01.taobaocdn.combao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpgimg01.taobaocdn.comhttp://img01.taobaocdn.com/bao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpg;,
host_len=19) at CacheRead.cc:231
#9 0x0069cfcf in Cache::open_read (this=0x3aeaf00,
cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0,
params=0x2b0e20735e08,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1080
#10 0x0069a9f6 in CacheProcessor::open_read (this=0xf44d30,
cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0,
params=0x2b0e20735e08,
pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3041
#11 0x0055937c in HttpCacheSM::do_cache_open_read
(this=0x2b0e20737fa8) at HttpCacheSM.cc:220
#12 0x005594cd in HttpCacheSM::open_read (this=0x2b0e20737fa8,
url=0x2b0e207365e8, hdr=0x2b0e207365d0, params=0x2b0e20735e08, pin_in_cache=0)
at HttpCacheSM.cc:252
#13 0x0057802d in HttpSM::do_cache_lookup_and_read
(this=0x2b0e20735d10) at HttpSM.cc:3911
#14 0x005808d6 in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6455
#15 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#16 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#17 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#18 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#19 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#20 0x00580391 in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6396
#21 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#22 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#23 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#24 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#25 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#26 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#27 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#28 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#29 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0x58f002
HttpTransact::ModifyRequest(HttpTransact::State*))
at HttpSM.cc:6346
#30 0x0056d45a in HttpSM::state_read_client_request_header
(this=0x2b0e20735d10, event=100, data=0x2b0e440157c8) at HttpSM.cc:783
#31 0x0056caf5 in HttpSM::setup_client_read_request_header
(this=0x2b0e20735d10) at HttpSM.cc:645
[jira] [Closed] (TS-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming closed TS-1154. - Resolution: Fixed checked in to the git 3.0.x branch. quick_filter on HEAD does not work -- Key: TS-1154 URL: https://issues.apache.org/jira/browse/TS-1154 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Zhao Yongming Assignee: weijin Fix For: 3.0.4 Attachments: head_method.diff we take quick filter as a good solution for some security concern, but when I set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. Weijin have the patch in our tree: https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd I will commit if no one complain in 2 days. -- 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] [Closed] (TS-970) ts crash when use evacuate feature
[
https://issues.apache.org/jira/browse/TS-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-970.
Resolution: Fixed
Fix Version/s: (was: 3.1.2)
3.1.1
Assignee: mohan_zl
this is fixed in r1199679
ts crash when use evacuate feature
--
Key: TS-970
URL: https://issues.apache.org/jira/browse/TS-970
Project: Traffic Server
Issue Type: Bug
Components: Cache
Environment: {noformat}
# uname -a
Linux cache170.cn63 2.6.32-131.4.1.tb204.el5.x86_64 #1 SMP Fri Jul 1 22:17:55
CST 2011 x86_64 x86_64 x86_64 GNU/Linux
{noformat}
Reporter: mohan_zl
Assignee: mohan_zl
Fix For: 3.1.1
Attachments: TS-970-1.patch
My config arguments:
start trafficserver in one machine 1
{code}
# traffic_line -s proxy.config.cache.hit_evacuate_percent -v 5 // by
default, the value is 0, means no evacuation
# cat storage.config //the size of storage file is 5G
/dev/sda1
{code}
My test method:
use http_load from another machine 2 to test machine 1
{code}
# http_load -parallel 500 -fetches 1000 -proxy xxx.xx.xx.xxx:8080
mohan_urls
# wc -l mohan_urls
40849490 mohan_urls
# sort mohan_urls | uniq -c mohan_urls_1; wc -l mohan_urls_1
14057051 mohan_urls_1
# ls -al
-rw-r--r-- 1 root root 3253681200 Sep 21 20:42 mohan_urls
-rw-r--r-- 1 root root 1305299567 Sep 21 21:27 mohan_urls_1
The total access urls' size is larger than the storage size
{code}
Crash result:
{code}
(gdb) bt
#0 0x003639c30265 in raise () from /lib64/libc.so.6
#1 0x003639c31d10 in abort () from /lib64/libc.so.6
#2 0x2aaaee6d86fa in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2aaaee6d8979 in ink_fatal_va (return_code=1,
message_format=0x424e6700 CacheWrite.cc:519: failed assert
`dir_pinned(dir)`,
ap=0x424e6600) at ink_error.cc:65
#4 0x2aaaee6d8b46 in ink_fatal (return_code=1, message_format=0x424e6700
CacheWrite.cc:519: failed assert `dir_pinned(dir)`)
at ink_error.cc:73
#5 0x2aaaee6d697a in _ink_assert (a=0x767108 dir_pinned(dir),
f=0x766a46 CacheWrite.cc, l=519) at ink_assert.cc:44
#6 0x006afaa2 in CacheVC::evacuateDocDone (this=0x2c371f80,
event=3900, e=0x0) at CacheWrite.cc:519
#7 0x004d3789 in Continuation::handleEvent (this=0x2c371f80,
event=3900, data=0x0) at I_Continuation.h:146
#8 0x006b0e7b in Vol::aggWrite (this=0x2e18a10, event=3900,
e=0x2e18ae0) at CacheWrite.cc:998
#9 0x006b1553 in Vol::evacuateWrite (this=0x2e18a10,
evacuator=0x2c371f80, event=3900, e=0x2e18ae0) at CacheWrite.cc:603
#10 0x006b2031 in Vol::evacuateDocReadDone (this=0x2e18a10,
event=3900, e=0x2e18ae0) at CacheWrite.cc:687
#11 0x004d3789 in Continuation::handleEvent (this=0x2e18a10,
event=3900, data=0x2e18ae0) at I_Continuation.h:146
#12 0x0068a532 in AIOCallbackInternal::io_complete (this=0x2e18ae0,
event=1, data=0x30687d0) at P_AIO.h:80
#13 0x004d3789 in Continuation::handleEvent (this=0x2e18ae0, event=1,
data=0x30687d0) at I_Continuation.h:146
#14 0x006f69b0 in EThread::process_event (this=0x2b22d010,
e=0x30687d0, calling_code=1) at UnixEThread.cc:142
#15 0x006f6cf2 in EThread::execute (this=0x2b22d010) at
UnixEThread.cc:219
#16 0x006f6337 in spawn_thread_internal (a=0x2d75190) at Thread.cc:88
#17 0x00363a8064a7 in start_thread () from /lib64/libpthread.so.0
#18 0x003639cd3c2d in clone () from /lib64/libc.so.6
{code}
{code}
(gdb) f 6
#6 0x006afaa2 in CacheVC::evacuateDocDone (this=0x2c371f80,
event=3900, e=0x0) at CacheWrite.cc:519
519 ink_assert(dir_pinned(dir));
(gdb) p cod-num_writers
$1 = 1
(gdb) p cod-max_writers
$2 = 5
(gdb) p cod-dont_update_directory
$3 = false
(gdb) p cod-move_resident_alt
$4 = false
(gdb) p cod-reading_vec
$5 = false
(gdb) p cod-writing_vec
$6 = true
(gdb) p cod-first_dir
$7 = {w = {61517, 5121, 14401, 59410, 0}}
(gdb) p cod-single_doc_dir
$8 = {w = {61517, 5121, 12585, 59410, 0}}
(gdb) p this-dir
$9 = {w = {10203, 5167, 14401, 59409, 0}}
(gdb) p this-overwrite_dir
$10 = {w = {20152, 5167, 10305, 59409, 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] [Closed] (TS-994) X-Forwarded-For should follow the squid way
[
https://issues.apache.org/jira/browse/TS-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-994.
Resolution: Fixed
X-Forwarded-For should follow the squid way
---
Key: TS-994
URL: https://issues.apache.org/jira/browse/TS-994
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.1
Attachments: XFF.patch
TS will append the IP in the format of:
{code}
X-Forwarded-For: 127.0.0.1, 10.32.102.41\r\n
{code}
while http://en.wikipedia.org/wiki/X-Forwarded-For says:
{code}
X-Forwarded-For: client1, proxy1, proxy2
{code}
there is 2 spaces in TS X-Forwarded-For header.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-913) logging in collation client mode will report with incorrect space warning
[
https://issues.apache.org/jira/browse/TS-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-913.
Resolution: Fixed
logging in collation client mode will report with incorrect space warning
-
Key: TS-913
URL: https://issues.apache.org/jira/browse/TS-913
Project: Traffic Server
Issue Type: Improvement
Components: Documentation, Logging
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.1
when collation mode set to 2, you can get a WARNING in traffic.out when
server started:
{code}
WARNING: Access logging to local log directory suspended - configured space
allocation exhausted.
{code}
this is by far not the case, it should print something like:
{code}
NOTE: Access logging to local log directory suspended - remote collation is
activated
{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] [Closed] (TS-932) Crash report: m_pending_event == NULL, f=0x746fb5 LogCollationClientSM.cc, l=203
[
https://issues.apache.org/jira/browse/TS-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-932.
Resolution: Fixed
Assignee: Zhao Yongming
Crash report: m_pending_event == NULL, f=0x746fb5
LogCollationClientSM.cc, l=203
-
Key: TS-932
URL: https://issues.apache.org/jira/browse/TS-932
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.0
Environment: custom logging as collation client
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
Labels: crash
Fix For: 3.1.1
Attachments: log_crash.diff, log_crash_2.diff
when testing in TS-896, I have get a crash with the following bt:
{code}
Program terminated with signal 6, Aborted.
#0 0x2ab83c300935 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x2ab83c300935 in raise () from /lib64/libc.so.6
#1 0x2ab83c301db6 in abort () from /lib64/libc.so.6
#2 0x2ab83a1165f8 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2ab83a1166ca in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2ab84690b4e0 LogCollationClientSM.cc:203: failed assert
`m_pending_event == NULL`, ap=0x2ab84690b3e0)
at ink_error.cc:65
#4 0x2ab83a116795 in ink_fatal (return_code=1,
message_format=0x2ab84690b4e0 LogCollationClientSM.cc:203: failed assert
`m_pending_event == NULL`) at ink_error.cc:73
#5 0x2ab83a11524e in _ink_assert (a=0x74722b m_pending_event == NULL,
f=0x746fb5 LogCollationClientSM.cc, l=203)
at ink_assert.cc:44
#6 0x0060d330 in LogCollationClientSM::send (this=0x2ab843c2b980,
log_buffer=0x2ab8407a4410) at LogCollationClientSM.cc:203
#7 0x0060c14c in LogHost::write (this=0x2ab843c39bc0,
lb=0x2ab840849bd0, to_disk=0x2ab84690bcc8, to_net=0x2ab84690bcc0,
to_pipe=0x2ab84690bcb8) at LogConfigCollation.cc:243
#8 0x0060a054 in LogHostList::write (this=0x2ab843bbcd50,
lb=0x2ab840849bd0, to_disk=0x2ab84690bcc8, to_net=0x2ab84690bcc0,
to_pipe=0x2ab84690bcb8) at LogHost.cc:380
#9 0x00600db4 in LogBufferManager::flush_buffers
(this=0x2ab843bbcdb8, sink=0x2ab843bbcd50, to_disk=0x2ab84690bcc8,
to_net=0x2ab84690bcc0, to_pipe=0x2ab84690bcb8) at LogObject.cc:65
#10 0x005eb2ed in LogObject::flush_buffers (this=0x2ab843bbcd20,
to_disk=0x2ab84690bcc8, to_net=0x2ab84690bcc0,
to_pipe=0x2ab84690bcb8) at LogObject.h:169
#11 0x00604cf8 in LogObjectManager::flush_buffers
(this=0x2ab843bd3fa0, to_disk=0x2ab84690bcc8, to_net=0x2ab84690bcc0,
to_pipe=0x2ab84690bcb8) at LogObject.cc:1170
#12 0x005e9ca9 in Log::flush_thread_main (args=0x0) at Log.cc:1132
#13 0x005eb4db in LoggingFlushContinuation::mainEvent
(this=0x2ab840cb6200, event=1, data=0xfd4fa0) at Log.cc:272
#14 0x004ea432 in Continuation::handleEvent (this=0x2ab840cb6200,
event=1, data=0xfd4fa0)
at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ffe4d in EThread::execute (this=0x2ab84670b010) at
UnixEThread.cc:287
#16 0x006fe832 in spawn_thread_internal (a=0x2ab840cbedd0) at
Thread.cc:88
#17 0x2ab83a358d4c in start_thread () from /lib64/libpthread.so.0
#18 0x2ab83c3a540d in clone () from /lib64/libc.so.6
{code}
this is really rare
--
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] [Closed] (TS-931) cluster latency too high, about 24ms
[ https://issues.apache.org/jira/browse/TS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming closed TS-931. Resolution: Fixed cluster latency too high, about 24ms Key: TS-931 URL: https://issues.apache.org/jira/browse/TS-931 Project: Traffic Server Issue Type: Improvement Components: Clustering Affects Versions: 3.1.1, 3.0.1 Environment: cluster type 1, content hashing Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.1 Attachments: cluster_performance.patch when we enable full clustering, the performance is unacceptable, it add about 24ms per request. we'd expect 10ms latency for each cluster request. this issue is for weijin :D -- 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
