[jira] [Updated] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1114:
--
Backport to Version: 3.0.5 (was: 3.0.4)
Crash report: HttpTransactCache::SelectFromAlternates
-
Key: TS-1114
URL: https://issues.apache.org/jira/browse/TS-1114
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
Attachments: cache_crash.diff
it may or may not be the upstream issue, let us open it for tracking.
{code}
#0 0x0053075e in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
1375((int32_t *) val)[0] = m_alt-m_object_key[0];
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1049: --- Backport to Version: 3.0.5 (was: 3.0.3) TS hangs (dead lock) on HTTPS POST requests --- Key: TS-1049 URL: https://issues.apache.org/jira/browse/TS-1049 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Affects Versions: 3.1.1, 3.1.0, 3.0.2 Environment: RedHat Enterprise Linux 6.0, Intel 32-bit Reporter: Wilson Ho Assignee: Igor Galić Priority: Blocker Fix For: 3.1.2 Attachments: records.config A very reproducible bug where the body of a HTTPS POST request is never forwarded to the origin server. Client submits a HTTPS POST request to TS, which is supposed to forward to the backend/origin server via HTTP. TS process the HTTP headers and establishes connection to the origin server, but the body of the HTTPS POST is never read. This hangs until the client times out and shuts down the connection. To reproduce: # Client connects to TS using HTTPS (works OK if it is just HTTP). # It must be a POST request. # TS must use at least 2 worker threads. # Easier to reproduce when the connections to the origin server is HTTP (not HTTPS). # POST body must be large enough so that the HTTP request headers and POST body do *NOT* fit within the same TCP packet. (2000 bytes is a good size) # I can consistently reproduce this problem using 2 separate clients each simultaneously submitting 2 requests back to back (i.e., 2 requests from each client, a total of 4 requests). This gives you a high probability that at least one of the requests would hang. Observation: # Thread A accepted and processed the HTTP headers, and called UnixNetProcessor::connect_re to prepare a new connection to the origin server. # Thread A must not have read the body of the POST. Otherwise, it works fine. # Thread B was assigned the task to handle the origin server connection. If the same thread A was picked, then everything works fine. # Apparently, one of the first things that thread B does is to acquire the mutex for reading from the client. (Why does it do that??) # While thread B was holding the mutex, thread A proceeded in SSLNetVConnection::net_read_io, tried and failed to acquire the mutex. Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but gave up after the second failure. But if thread B released the mutex soon enough, that thread A could proceed happily and everything works. # From this point, the body of the POST is never read from the client, and there is nothing to be proxy'd to the origin server, and both the consumer and producer tasks are never scheduled to run again -- or until the client times out. I tried setting the client-side time out to as long as 3-5 minutes and TS really does not recover by itself until the client closed the connection. This is the first time I uses this bug system. Please let me know how I could produce the configuration files and trace logs, etc. Thanks! -- 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-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1164: --- Fix Version/s: (was: 3.1.4) This hasn't been fixed yet, so I'm removing the fix version. a race condition in cache init --- Key: TS-1164 URL: https://issues.apache.org/jira/browse/TS-1164 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.1, 3.0.0 Environment: all Reporter: weijin Assignee: weijin Attachments: taorui-cache.diff there is a race condition in CacheProcessor::diskInitialized, which may lead to cache can not be enabled. -- 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] [Issue Comment Edited] (TS-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246197#comment-13246197 ] Igor Galić edited comment on TS-1164 at 4/4/12 12:13 PM: - This hasn't been committed yet, so I'm removing the fix version. was (Author: i.galic): This hasn't been fixed yet, so I'm removing the fix version. a race condition in cache init --- Key: TS-1164 URL: https://issues.apache.org/jira/browse/TS-1164 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.1, 3.0.0 Environment: all Reporter: weijin Assignee: weijin Attachments: taorui-cache.diff there is a race condition in CacheProcessor::diskInitialized, which may lead to cache can not be enabled. -- 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-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1164: --- Fix Version/s: 3.1.4 a race condition in cache init --- Key: TS-1164 URL: https://issues.apache.org/jira/browse/TS-1164 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.1, 3.0.0 Environment: all Reporter: weijin Assignee: weijin Fix For: 3.1.4 Attachments: taorui-cache.diff there is a race condition in CacheProcessor::diskInitialized, which may lead to cache can not be enabled. -- 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-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1164: --- Comment: was deleted (was: This hasn't been committed yet, so I'm removing the fix version.) a race condition in cache init --- Key: TS-1164 URL: https://issues.apache.org/jira/browse/TS-1164 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.1, 3.0.0 Environment: all Reporter: weijin Assignee: weijin Fix For: 3.1.4 Attachments: taorui-cache.diff there is a race condition in CacheProcessor::diskInitialized, which may lead to cache can not be enabled. -- 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-1111) crash in RangeTransform::handle_event
[
https://issues.apache.org/jira/browse/TS-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-:
---
Backport to Version: 3.0.5
crash in RangeTransform::handle_event
-
Key: TS-
URL: https://issues.apache.org/jira/browse/TS-
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Labels: crash
Fix For: 3.1.3
Attachments: transform.patch
we have some crashing in range requesting processing, it is on our own tree
based on 3.0.x, that maybe the root cause of the do_io_close issue, we are
still look at how to fix that, feedback is welcome
{code}
#0 0x004dc624 in RangeTransform::handle_event (this=0x2aaed0001fb0,
event=1, edata=value optimized out) at Transform.cc:926
926 Debug(transform_range, RangeTransform destroy: %d,
m_output_vio ? m_output_vio-ndone : 0);
(gdb) bt
#0 0x004dc624 in RangeTransform::handle_event (this=0x2aaed0001fb0,
event=1, edata=value optimized out) at Transform.cc:926
#1 0x0069145f in EThread::process_event (this=0x2b332010,
e=0x591d410, calling_code=1) at I_Continuation.h:146
#2 0x00691b8b in EThread::execute (this=0x2b332010) at
UnixEThread.cc:218
#3 0x0069092e in spawn_thread_internal (a=0x440bfa0) at Thread.cc:88
#4 0x00359fe0673d in pthread_create@@GLIBC_2.2.5 () from
/lib64/libpthread.so.0
#5 0x in ?? ()
(gdb) p m_output_vio
$1 = (VIO *) 0x2aaed0029fe8
(gdb) p *m_output_vio
Cannot access memory at address 0x2aaed0029fe8
{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-949) key-volume hash table is not consistent when a disk is marked as bad or removed due to failure
[
https://issues.apache.org/jira/browse/TS-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-949:
--
Backport to Version: 3.0.5
key-volume hash table is not consistent when a disk is marked as bad or
removed due to failure
---
Key: TS-949
URL: https://issues.apache.org/jira/browse/TS-949
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.1.0
Environment: Multi-volume cache with apparently faulty drives
Reporter: B Wyatt
Assignee: John Plevyak
Fix For: 3.1.2
Attachments: TS-949-jp-1.patch, TS-949-jp2.patch, TS949-BW-p1.patch,
explicit-pair.patch
The method for resolving collisions when distributing hash-table space to
volumes for the object_key-volume hash table creates inconsistency when a
disk is determined to be bad, or when a failed disk is removed from the
volume.config.
Background:
The hash space is distributed by round robin draft where each volume drafts
a random index in the hash table until the hash space is exhausted. The
random order in which a given volume drafts hash table slots is consistent
across reboot/crash/disk-failure, however when a volume attempts to draft a
slot which has already been occupied, it skips to its next random pick and
attempts to draft that slot until it finds an open slot. This ensures that
the hash is partitioned evenly between volumes.
The issue:
Resolving slot contention breaks the consistency as it is dependent on the
order that the volumes draft. When rebuilding the hash after disk failure or
reboot with fewer drives, a volume may secure an index that was previously
occupied by the dead-disk. In the old hash, the surviving volume would have
selected another random index due to contention. If this index is taken, by
the next draft round it will represent an inconsistent key-volume result.
The effects of one inconsistency will then cascade as whichever volume
occupies that index after removing a dead disk is now behind on its draft
sequence as well.
An Example:
||Disk||Draft Sequence||
|A|1,4,7,5|
|B|4,2,8,1|
|C|3,7,5,2|
Pre-failure Hash Table after 2 rounds of draft:
|A|B|C|B|C|?|A|?|
Post-failure of drive B Hash Table after 3 rounds of draft:
|A|C|C|A|{color:red}A{color}|?|{color:red}C{color}|?|
Two slots have become inconsistent and more will probably follow. These
inconsistencies become objects stored in a volume but lost to the top level
cache for open/lookup.
--
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-1109) stack dump may crash too
[ https://issues.apache.org/jira/browse/TS-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1109: --- Backport to Version: 3.0.5 stack dump may crash too Key: TS-1109 URL: https://issues.apache.org/jira/browse/TS-1109 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.2 Reporter: Zhao Yongming Assignee: weijin Labels: crash Fix For: 3.1.3 Attachments: cop_crash.diff the codes doing stack dump may crash, in this case you will not able to get a core file, that will hide most of the rare issues. -- 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-1184) Additional whitespace in proxy.config.admin.user_id value results in error
[
https://issues.apache.org/jira/browse/TS-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-1184:
---
Description:
Config looked like this:
{noformat}
CONFIG proxy.config.alarm_email STRING nobody
{noformat}
The username had a trailing space. ATS fails to start, and the following
messages appear in {{/var/log/messages:}}
{noformat}
Apr 3 10:46:33 blitz traffic_cop[5498]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:46)] ---
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: traffic_manager not running, making
sure traffic_server is dead
Apr 3 10:46:33 blitz traffic_cop[5498]: spawning traffic_manager
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: --- Manager Starting ---
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:03)
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE:
RLIMIT_NOFILE(7):cur(3),max(3)
Apr 3 10:46:33 blitz traffic_manager[5500]: {140630387636192} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: --- Server Starting ---
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:30)
Apr 3 10:46:35 blitz traffic_server[5509]: {47289782682464} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
{noformat}
was:
Config looked like this:
CONFIG proxy.config.alarm_email STRING nobody
The username had a trailing space. ATS fails to start, and the following
messages appear in /var/log/messages:
Apr 3 10:46:33 blitz traffic_cop[5498]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:46)] ---
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: traffic_manager not running, making
sure traffic_server is dead
Apr 3 10:46:33 blitz traffic_cop[5498]: spawning traffic_manager
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: --- Manager Starting ---
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:03)
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE:
RLIMIT_NOFILE(7):cur(3),max(3)
Apr 3 10:46:33 blitz traffic_manager[5500]: {140630387636192} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: --- Server Starting ---
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:30)
Apr 3 10:46:35 blitz traffic_server[5509]: {47289782682464} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
Fascinating. I didn't even know we used that config option.
Kurt, does this type of error occur also with
{noformat}
CONFIG proxy.config.admin.user_id STRING nobody
{noformat}
Additional whitespace in proxy.config.admin.user_id value results in error
--
Key: TS-1184
URL: https://issues.apache.org/jira/browse/TS-1184
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.4
Reporter: Kurt Payne
Priority: Minor
Config looked like this:
{noformat}
CONFIG proxy.config.alarm_email STRING nobody
{noformat}
The username had a trailing space. ATS fails to start, and the following
messages appear in {{/var/log/messages:}}
{noformat}
Apr 3 10:46:33 blitz traffic_cop[5498]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:46)] ---
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: traffic_manager not running, making
sure traffic_server is dead
Apr 3 10:46:33 blitz traffic_cop[5498]: spawning traffic_manager
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: --- Manager Starting ---
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:03)
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE:
RLIMIT_NOFILE(7):cur(3),max(3)
Apr 3 10:46:33 blitz
[jira] [Reopened] (TS-703) cannot find server response 502 :( plz help me!!
[ https://issues.apache.org/jira/browse/TS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reopened TS-703: --- Backport to Version: 3.3.0 When using the configuration option: proxy.config.dns.search_default_domains 1 There can be problems with using localhost as the destination hostname in remap. ATS will first start using the search domains and looks like it stops after 4 lookups and doesn't try to lookup localhost. This was also observed in YTS, however YTS doesn't lookup for the hostnames also. Suggested changes: 1. set proxy.config.dns.search_default_domains to 0 by default either one: 2a. special case localhost and having it resolve before appending the search domains 2b. always try to resolve the hostname before appending search domains (my vote is for 2b.) More testing should be done with different hostnames in the destination of the remap rule to see if there are other issues. cannot find server response 502 :( plz help me!! Key: TS-703 URL: https://issues.apache.org/jira/browse/TS-703 Project: Traffic Server Issue Type: Test Reporter: KenYun Finally, I installed ASF with a rpm vesrsion but I faced with the other problem as you see just under. I will really appreciate if you could help me :) This just under is a message after I put ' curl -v http://localhost/ ' to test if AFS works. ] curl -v http://localhost/ . . . !-- default Cannnot find server. response (502) -- FYI, Of course I did following things, CONFIG proxy.config.proxy_name STRING kenyun CONFIG proxy.config.http.server_port INT 80 map http://localhost:80/ http://localhost:8080/ map http://kenyun:80/ http://localhost:8080/ Listen 8080 Plz tell me if I did something wrong here ㅠㅠ -- 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-703) cannot find server response 502 :( plz help me!!
[
https://issues.apache.org/jira/browse/TS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246436#comment-13246436
]
Bryan Call commented on TS-703:
---
Debug from ATS (I think I forgot to copy the last lookup in my notes):
[bcall@ ~]$ sudo /home/y/bin64/traffic_server -T dns 2/dev/stdout | grep send
[Apr 3 17:11:22.040] Server {0x7f1ccd930720} DEBUG: (dns) send query (qtype=1)
for localhost.mud.yahoo.com to fd 67
[Apr 3 17:11:22.041] Server {0x7f1ccd930720} DEBUG: (dns) send query
(qtype=28) for localhost.mud.yahoo.com to fd 67
[Apr 3 17:11:22.041] Server {0x7f1ccd930720} DEBUG: (dns) send query
(qtype=28) for localhost.mud.yahoo.com.yahoo.com to fd 67
Debug from YTS:
[bcall@ ~]$ sudo /home/y/bin64/traffic_server -T dns 2/dev/stdout | grep send
[Apr 3 17:05:14.339] Server {4146587904} DEBUG: (dns) send query for
localhost.ac4.yahoo.com to fd 183
[Apr 3 17:05:14.341] Server {4146587904} DEBUG: (dns) send query for
localhost.yahoo.com to fd 183
[Apr 3 17:05:14.344] Server {4146587904} DEBUG: (dns) send query for localhost
to fd 183
cannot find server response 502 :( plz help me!!
Key: TS-703
URL: https://issues.apache.org/jira/browse/TS-703
Project: Traffic Server
Issue Type: Test
Reporter: KenYun
Finally, I installed ASF with a rpm vesrsion but I faced with the other
problem as you see just under.
I will really appreciate if you could help me :)
This just under is a message after I put ' curl -v http://localhost/ ' to
test if AFS works.
] curl -v http://localhost/
.
.
.
!-- default Cannnot find server. response (502) --
FYI,
Of course I did following things,
CONFIG proxy.config.proxy_name STRING kenyun
CONFIG proxy.config.http.server_port INT 80
map http://localhost:80/ http://localhost:8080/
map http://kenyun:80/ http://localhost:8080/
Listen 8080
Plz tell me if I did something wrong here ㅠㅠ
--
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-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] [Updated] (TS-703) cannot find server response 502 :( plz help me!!
[ https://issues.apache.org/jira/browse/TS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-703: -- Backport to Version: (was: 3.3.0) Fix Version/s: 3.3.0 cannot find server response 502 :( plz help me!! Key: TS-703 URL: https://issues.apache.org/jira/browse/TS-703 Project: Traffic Server Issue Type: Test Reporter: KenYun Fix For: 3.3.0 Finally, I installed ASF with a rpm vesrsion but I faced with the other problem as you see just under. I will really appreciate if you could help me :) This just under is a message after I put ' curl -v http://localhost/ ' to test if AFS works. ] curl -v http://localhost/ . . . !-- default Cannnot find server. response (502) -- FYI, Of course I did following things, CONFIG proxy.config.proxy_name STRING kenyun CONFIG proxy.config.http.server_port INT 80 map http://localhost:80/ http://localhost:8080/ map http://kenyun:80/ http://localhost:8080/ Listen 8080 Plz tell me if I did something wrong here ㅠㅠ -- 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] [Created] (TS-1186) Problem with Perl stats API not parsing the stats as 64-bit int
Problem with Perl stats API not parsing the stats as 64-bit int --- Key: TS-1186 URL: https://issues.apache.org/jira/browse/TS-1186 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.3 Environment: RHEL 6.2 Reporter: Bryan Call Assignee: Bryan Call Priority: Minor Fix For: 3.1.4 Stats will rollover because they are parsed as 32-bit int instead of 64-bit int in the Apache::TS::AdminClient module. Change: -@resp = unpack( slsl, $res ); +@resp = unpack( slsq, $res ); -- 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] [Created] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Fix For: 3.1.4 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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] [Created] (TS-1188) http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404
http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404 Key: TS-1188 URL: https://issues.apache.org/jira/browse/TS-1188 Project: Traffic Server Issue Type: Bug Components: Web site Reporter: James Peach Assignee: Igor Galić Priority: Minor The main docs page tries to point to the Chinese admin docs at http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf, but there's nothing there. -- 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-1188) http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404
[ https://issues.apache.org/jira/browse/TS-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246486#comment-13246486 ] Eric Ahn commented on TS-1188: -- step as follow : 1) http://trafficserver.apache.org/docs/ 2) Traffic Server 管理员指南 (PDF) - click 3) message is Not Found The requested URL /docs/trunk/admin/ts_admin_chinese.pdf was not found on this server. http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404 Key: TS-1188 URL: https://issues.apache.org/jira/browse/TS-1188 Project: Traffic Server Issue Type: Bug Components: Web site Reporter: James Peach Assignee: Igor Galić Priority: Minor The main docs page tries to point to the Chinese admin docs at http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf, but there's nothing there. -- 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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Backport to Version: (was: 3.0.4) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.1.4 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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-1188) http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404
[ https://issues.apache.org/jira/browse/TS-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-1188. Resolution: Fixed http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404 Key: TS-1188 URL: https://issues.apache.org/jira/browse/TS-1188 Project: Traffic Server Issue Type: Bug Components: Web site Reporter: James Peach Assignee: Igor Galić Priority: Minor The main docs page tries to point to the Chinese admin docs at http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf, but there's nothing there. -- 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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246627#comment-13246627 ] Eric Ahn commented on TS-1187: -- I just figure it out, It set headers using TSMimeHdrFieldNameSet, looks like myheader : header-value. but can't sent client or origin server. In case of sending cache to origin server, it appears only header name, that is myheader : , in origin server, but, can't see value header-value. TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.1.4 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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-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] [Updated] (TS-1085) traffic_shell enable command doesn't work
[ https://issues.apache.org/jira/browse/TS-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1085: Fix Version/s: (was: 3.1.4) 3.3.0 Maybe we will fix this by removing traffic_shell in 3.3. traffic_shell enable command doesn't work - Key: TS-1085 URL: https://issues.apache.org/jira/browse/TS-1085 Project: Traffic Server Issue Type: Bug Components: Management Reporter: James Peach Assignee: James Peach Fix For: 3.3.0 Let's try this as root: blacko:trafficserver.git jpeach$ sudo /opt/ats/bin/traffic_shell Successfully Initialized MgmtAPI in /opt/ats/var/trafficserver % trafficserver enable Already Enabled trafficserver exit Ok, to let's try as non-root: blacko:trafficserver.git jpeach$ /opt/ats/bin/traffic_shell [connect] ERROR (main_socket_fd 3): Permission denied TSInit 5: Failed to initialize MgmtAPI in /opt/ats/var/trafficserver [connect] ERROR (main_socket_fd 3): Permission denied % trafficserver enable FATAL: ConfigCmd.cc:137: failed assert `enable_restricted_commands` /opt/ats/bin/traffic_shell - STACK TRACE: 0 libtsutil.3.dylib 0x00010cec8b8b ink_fatal_va + 283 1 libtsutil.3.dylib 0x00010cec8e94 ink_fatal + 356 2 libtsutil.3.dylib 0x00010cec66ff _ink_assert + 271 3 traffic_shell 0x00010ce253ab _Z10Cmd_EnablePvP10Tcl_InterpiPPKc + 395 4 Tcl 0x00010cf34261 TclInvokeStringCommand + 121 5 Tcl 0x00010cf360b7 Tcl_GetMathFuncInfo + 2533 6 Tcl 0x00010cf36d14 Tcl_GetMathFuncInfo + 5698 7 Tcl 0x00010cf370d2 Tcl_Eval + 42 So either enable does nothing or it crashes. Seems like we should fix or remove this. -- 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-1054) TSFetchUrl takes an address but does the DNS lookup anyway
[
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1054:
Fix Version/s: (was: 3.1.4)
3.3.0
I won't have time to investigate for 3.2. Move out to 3.3.
TSFetchUrl takes an address but does the DNS lookup anyway
--
Key: TS-1054
URL: https://issues.apache.org/jira/browse/TS-1054
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.2
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.3.0
TSFetchUrl() takes an IP address as one of its arguments, so the API client
has to resolve the hostname portion of any URL it wants to fetch. However
once you get into the HTTP state machine, the host gets resolved again. One
of these DNS queries is redundant for performance reasons. Additionally, the
plugin might have some special knowledge about which IP address to use that
the DNS resolver doesn't, in which case the result would be wrong.
[Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request
(90 of 90 bytes):
GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
accept: */*
[Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM
initialized for request with headers
--
GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
accept: */*
--
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect]
calling httpconnect write
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created
PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq)
HttpAccept:mainEvent] accepted connection
[Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session
born, netvc 0x102872e10
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using
accept inactivity timeout [120 seconds]
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting
transaction 1 using sm [0]
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
do_io_read for 0 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
do_io_read for -1 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
do_io_read for -1 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
do_io_write for 90 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive:
Received event 1
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; act_on 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
closed? 0 shutdown? 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active:
Received event 1
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_read_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_read_side; act_on 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
closed? 0 shutdown? 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side; act_on 90
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side; added 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[fetch_handler] calling fetch_plugin
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_write] calling process write
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; act_on 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; added 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
[HttpSM::main_handler, VC_EVENT_READ_READY]
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
[HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] done parsing
client request header
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
reenable Read
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START
HttpTransact::ModifyRequest
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans)
[ink_cluster_time] local: 1323923789, highest_delta: 0, cluster: 1323923789
[jira] [Commented] (TS-1085) traffic_shell enable command doesn't work
[
https://issues.apache.org/jira/browse/TS-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246999#comment-13246999
]
Zhao Yongming commented on TS-1085:
---
I think that is because of traffic_shell traffic_line need write permission
on the unix socks, where in most case they are owned by nobody or ats, and
permission 0755:
{code}
[root@test55 trafficserver]# ls -l /var/run/trafficserver/ | grep ^s
srwxr-xr-x 1 ats ats 0 Apr 5 10:09 eventapisocket
srwxr-xr-x 1 ats ats 0 Apr 5 10:09 mgmtapisocket
srwxr-xr-x 1 ats ats 0 Apr 5 10:09 process_server
{code}
in any way, you can not write to those socks unless you are root, that is why
traffic_line traffic_shell need the root privileges.
traffic_shell enable command doesn't work
-
Key: TS-1085
URL: https://issues.apache.org/jira/browse/TS-1085
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: James Peach
Assignee: James Peach
Fix For: 3.3.0
Let's try this as root:
blacko:trafficserver.git jpeach$ sudo /opt/ats/bin/traffic_shell
Successfully Initialized MgmtAPI in /opt/ats/var/trafficserver
% trafficserver enable
Already Enabled
trafficserver exit
Ok, to let's try as non-root:
blacko:trafficserver.git jpeach$ /opt/ats/bin/traffic_shell
[connect] ERROR (main_socket_fd 3): Permission denied
TSInit 5: Failed to initialize MgmtAPI in /opt/ats/var/trafficserver
[connect] ERROR (main_socket_fd 3): Permission denied
% trafficserver enable
FATAL: ConfigCmd.cc:137: failed assert `enable_restricted_commands`
/opt/ats/bin/traffic_shell - STACK TRACE:
0 libtsutil.3.dylib 0x00010cec8b8b ink_fatal_va + 283
1 libtsutil.3.dylib 0x00010cec8e94 ink_fatal + 356
2 libtsutil.3.dylib 0x00010cec66ff _ink_assert + 271
3 traffic_shell 0x00010ce253ab
_Z10Cmd_EnablePvP10Tcl_InterpiPPKc + 395
4 Tcl 0x00010cf34261
TclInvokeStringCommand + 121
5 Tcl 0x00010cf360b7
Tcl_GetMathFuncInfo + 2533
6 Tcl 0x00010cf36d14
Tcl_GetMathFuncInfo + 5698
7 Tcl 0x00010cf370d2 Tcl_Eval + 42
So either enable does nothing or it crashes. Seems like we should fix or
remove this.
--
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
