[jira] [Updated] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2437: Attachment: (was: TS-2437.diff) Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2437: Attachment: TS-2437.diff Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2437: Attachment: (was: TS-2437.diff) Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2437: Attachment: TS-2437.diff Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-2488: - Component/s: Plugins any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2489) contents between !--esi and -- output twice when the node list cached
[ https://issues.apache.org/jira/browse/TS-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-2489: - Component/s: Plugins contents between !--esi and -- output twice when the node list cached --- Key: TS-2489 URL: https://issues.apache.org/jira/browse/TS-2489 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Fix For: 4.2.0 Attachments: 0001-TS-2489-contents-between-esi-and-output-twice.patch in esi plugin, when the node list is retrieved from cache with the option --packed-node-support, the contents between !--esi and -- will output twice. the test case is: html head/head body !--esi p esi:include src=/data/data.htm/ /p -- /body /html the body of URL: /data/data.htm is haha. the output will be: html head/head body p haha /p p haha /p /body /html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869642#comment-13869642 ] ASF subversion and git services commented on TS-2488: - Commit 91f3cce290bf9a95f8df757582dd6578204ceb28 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=91f3cce ] [TS-2488] enhance esi plugin to allow any of the space characters to follow esi starting tags any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869653#comment-13869653 ] Kit Chan commented on TS-2488: -- Thanks for the patch any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869673#comment-13869673 ] Kit Chan commented on TS-2488: -- you can see the error with make test any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869689#comment-13869689 ] ASF subversion and git services commented on TS-2488: - Commit 283aa3bca9551067c701d0e2fc1d4ebe313e3d1e in branch refs/heads/master from [~kichan] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=283aa3b ] [TS-2488] temporarily commenting out the failing tests any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1956:
--
Fix Version/s: (was: 5.0.0)
sometime
Under Heavy Load TS 3.3.4-dev can't (re)start
-
Key: TS-1956
URL: https://issues.apache.org/jira/browse/TS-1956
Project: Traffic Server
Issue Type: Bug
Reporter: Tommy Lee
Priority: Blocker
Labels: Crash
Fix For: sometime
Attachments: backtrace.log
Hi,
We run TS in forward mode, under REALLY HEAVY load. Currently we run version
3.3.2-dev without problems.
But today, we tried to upgrade to version 3.3.4-dev without lucky.
We've noticed that, if TS restarts, it enters in this Segfault Loop.
Below are traffic.out logs with debug .*
I'll try to debug with GDB too, but I cannot stop this server for too long,
because of our operations.
Thanks in advance.
{code}
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fd9e0 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fdd00 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.81.5:46089 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.101.4:41361 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.156.38:59164 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c00] accepted connection from
10.202.81.5:46089 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.35.9:51533 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.201.20:10964 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
10.200.156.38:59164 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.148.2:44203 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fe020 on port 3128 as inbound transparent
[Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
10.202.101.4:41361 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015540] accepted connection from
10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
Segmentation fault
/usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
NOTE: Traffic Server received Sig 11: Segmentation fault
[Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
- STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.131.24:65434 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.157.26:52514 -
[jira] [Commented] (TS-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869715#comment-13869715
]
Leif Hedstrom commented on TS-1956:
---
[~tommylee] Is this still an issue in v4.1.2 ?
Under Heavy Load TS 3.3.4-dev can't (re)start
-
Key: TS-1956
URL: https://issues.apache.org/jira/browse/TS-1956
Project: Traffic Server
Issue Type: Bug
Reporter: Tommy Lee
Priority: Blocker
Labels: Crash
Fix For: sometime
Attachments: backtrace.log
Hi,
We run TS in forward mode, under REALLY HEAVY load. Currently we run version
3.3.2-dev without problems.
But today, we tried to upgrade to version 3.3.4-dev without lucky.
We've noticed that, if TS restarts, it enters in this Segfault Loop.
Below are traffic.out logs with debug .*
I'll try to debug with GDB too, but I cannot stop this server for too long,
because of our operations.
Thanks in advance.
{code}
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fd9e0 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fdd00 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.81.5:46089 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.101.4:41361 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.156.38:59164 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c00] accepted connection from
10.202.81.5:46089 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.35.9:51533 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.201.20:10964 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
10.200.156.38:59164 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.148.2:44203 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fe020 on port 3128 as inbound transparent
[Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
10.202.101.4:41361 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015540] accepted connection from
10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
Segmentation fault
/usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
NOTE: Traffic Server received Sig 11: Segmentation fault
[Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
- STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.131.24:65434 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection
[jira] [Commented] (TS-2272) cache init is too slow
[
https://issues.apache.org/jira/browse/TS-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869717#comment-13869717
]
Leif Hedstrom commented on TS-2272:
---
Anything on this bug that's actionable? I'll close it in 3 days if no more
details.
Thanks!
cache init is too slow
--
Key: TS-2272
URL: https://issues.apache.org/jira/browse/TS-2272
Project: Traffic Server
Issue Type: Improvement
Components: Cache, Core
Affects Versions: 4.1.2
Reporter: Zhao Yongming
Assignee: weijin
Priority: Minor
from the log, that each disk is wasting about 1-3s to get initialized, looks
that is working in serial way, may need more work to get all disk done in 1-3s
{code}
[Oct 15 18:16:52.352] Server {0x2b77c9a19700} WARNING: disk header different
for disk /dev/sdd: clearing the disk
[Oct 15 18:16:52.359] Server {0x2b77c9413700} WARNING: disk header different
for disk /dev/sde: clearing the disk
[Oct 15 18:16:52.364] Server {0x2b77c9a19700} WARNING: disk header different
for disk /dev/sdf: clearing the disk
[Oct 15 18:16:52.369] Server {0x2b77c9413700} WARNING: disk header different
for disk /dev/sdg: clearing the disk
[Oct 15 18:16:52.375] Server {0x2b77c9c1b700} WARNING: disk header different
for disk /dev/sdh: clearing the disk
[Oct 15 18:16:52.382] Server {0x2b77c28c1e40} NOTE: traffic server running
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdb
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdc
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdd
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sde
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdf
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdg
[Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdh
[Oct 15 18:16:52.474] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sdb 122880:73257708'
[Oct 15 18:16:53.637] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sdc 122880:73257708'
[Oct 15 18:16:54.797] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sdd 122880:73257708'
[Oct 15 18:16:55.961] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sde 122880:73257708'
[Oct 15 18:16:57.089] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sdf 122880:73257708'
[Oct 15 18:16:58.216] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sdg 122880:73257708'
[Oct 15 18:16:59.326] Server {0x2b77c9918700} NOTE: clearing cache directory
'/dev/sdh 122880:73257708'
[Oct 15 18:17:05.417] Server {0x2b77c9f1e700} NOTE: cache enabled
[Oct 15 18:17:16.811] {0x7f40b73847e0} STATUS: opened
/var/log/trafficserver/diags.log
[Oct 15 18:17:16.811] {0x7f40b73847e0} NOTE: updated diags config
[Oct 15 18:17:16.814] Server {0x7f40b73847e0} NOTE: cache clustering disabled
[Oct 15 18:17:16.840] Server {0x7f40b73847e0} NOTE: CLEAR
[Oct 15 18:17:16.840] Server {0x7f40b73847e0} NOTE: Clearing Configuration
[Oct 15 18:17:16.840] Server {0x7f40b73847e0} NOTE: Clearing Host Database
[Oct 15 18:17:16.858] Server {0x7f40b73847e0} NOTE: Clearing Cache
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdb
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdc
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdd
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sde
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdf
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdg
[Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdh
[Oct 15 18:17:16.903] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sdb 122880:73257708'
[Oct 15 18:17:18.162] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sdc 122880:73257708'
[Oct 15 18:17:19.391] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sdd 122880:73257708'
[Oct 15 18:17:20.608] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sde 122880:73257708'
[Oct 15 18:17:21.837] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sdf 122880:73257708'
[Oct 15 18:17:23.083] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sdg 122880:73257708'
[Oct 15 18:17:24.387] Server {0x7f40b40da700} NOTE: clearing cache directory
'/dev/sdh 122880:73257708'
[Oct 15 18:17:30.790] Server {0x7f40b3ad4700} NOTE: cache enabled
[Oct 15 18:17:30.956] Server {0x7f40b41db700} NOTE: CLEAR, succeeded
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2490) traffic_cop kills TS process before it completes starting
David Carlin created TS-2490: Summary: traffic_cop kills TS process before it completes starting Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869740#comment-13869740 ] Leif Hedstrom commented on TS-2490: --- Alan: Maybe this could go in with something related to the lifecycle stuff you added? I.e. it'd be reasonable for the lifecycle process to inform traffic_cop when it should be capable of testing the health / life ? traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Commented] (TS-2490) traffic_cop kills TS process before it completes starting
On Jan 13, 2014, at 9:50 AM, Leif Hedstrom (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869740#comment-13869740 ] Leif Hedstrom commented on TS-2490: --- Alan: Maybe this could go in with something related to the lifecycle stuff you added? I.e. it'd be reasonable for the lifecycle process to inform traffic_cop when it should be capable of testing the health / life ? I had a patch on TS-2058 to start the healtcheck server much earlier. Apparantly this didn't work right, but I think that it is the right way to go. One interesting application of the lifecycle hooks concept might be to allow plugins to register a healthcheck hook that would get polled as part of the traffic_cop healthcheck.
[jira] [Commented] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869949#comment-13869949 ] James Peach commented on TS-2490: - I had a patch on TS-2058 to start the healtcheck server much earlier. Apparantly this didn't work right, but I think that it is the right way to go. One interesting application of the lifecycle hooks concept might be to allow plugins to register a healthcheck hook that would get polled as part of the traffic_cop healthcheck. traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-2488: - Attachment: 2488.txt Additional changes to make unit tests work any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch, 2488.txt only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869961#comment-13869961 ] Kit Chan commented on TS-2488: -- I have added additional changes to try to make it work. Yu Qing, please make a look at the latest attachment. Here are some notes for that 1) I have removed the check for '/' because it wasn't mentioned what it is for. 2) I have commented out the line to skip the space char because this will cause test 42 in parser_test to fail 3) I have added code to fail when there is tag match without proper space character match. 4) I have added code to declare a partial match there is tag match but don't have enough character to do space character match. 5) I have split the processing case of VARS and HTML_COMMENTS so I can properly get data for the HTML_COMMENT node. That's needed for test 37-39 in parser_test 6) At the end we only change test case for test 9 and test 18 for parser test to accommodate the new logic related to space character match. Yu Qing, it will be great if you can review them before I commit. any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch, 2488.txt only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869982#comment-13869982 ] Leif Hedstrom commented on TS-2490: --- Hmmm, but that makes the proxy available early? Or just the health check portion of it? If the former, that won't work, but if it's the latter (isolated to health checks only), that seems reasonable. Although, i thought the whole point of the health check was that it would do an end to end test, but alas, I haven't actually spent any time in that code. traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-2483) Add 'cache status/readiness' metric to trafficserver
[ https://issues.apache.org/jira/browse/TS-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869998#comment-13869998 ] Leif Hedstrom edited comment on TS-2483 at 1/13/14 9:13 PM: This did not seem to work at all, lib records seems to trip over something (see James's emails), on OSX this segfaults. was (Author: zwoop): This did not seem to work at all, lib records seems to trip over something (see James's emails), on OSX. Add 'cache status/readiness' metric to trafficserver Key: TS-2483 URL: https://issues.apache.org/jira/browse/TS-2483 Project: Traffic Server Issue Type: Improvement Components: Cache, Management, Stats Reporter: Ben Haga Assignee: Leif Hedstrom Priority: Minor Fix For: sometime This is a request to add a 'cache readiness' metric (as a time value) to trafficserver. Currently, it is difficult to determine the state of the cache volumes unless trafficserver is configured not to serve traffic until the cache volumes have been brought online. It is desirable to have the ability to poll trafficserver's view of the cache volume(s) state (such as a timestamp of when the cache became ready) before or after the cache volumes become available to monitor state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2483) Add 'cache status/readiness' metric to trafficserver
[ https://issues.apache.org/jira/browse/TS-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2483: -- Fix Version/s: sometime Add 'cache status/readiness' metric to trafficserver Key: TS-2483 URL: https://issues.apache.org/jira/browse/TS-2483 Project: Traffic Server Issue Type: Improvement Components: Cache, Management, Stats Reporter: Ben Haga Assignee: Leif Hedstrom Priority: Minor Fix For: sometime This is a request to add a 'cache readiness' metric (as a time value) to trafficserver. Currently, it is difficult to determine the state of the cache volumes unless trafficserver is configured not to serve traffic until the cache volumes have been brought online. It is desirable to have the ability to poll trafficserver's view of the cache volume(s) state (such as a timestamp of when the cache became ready) before or after the cache volumes become available to monitor state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (TS-2483) Add 'cache status/readiness' metric to trafficserver
[ https://issues.apache.org/jira/browse/TS-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reopened TS-2483: --- Add 'cache status/readiness' metric to trafficserver Key: TS-2483 URL: https://issues.apache.org/jira/browse/TS-2483 Project: Traffic Server Issue Type: Improvement Components: Cache, Management, Stats Reporter: Ben Haga Assignee: Leif Hedstrom Priority: Minor Fix For: sometime This is a request to add a 'cache readiness' metric (as a time value) to trafficserver. Currently, it is difficult to determine the state of the cache volumes unless trafficserver is configured not to serve traffic until the cache volumes have been brought online. It is desirable to have the ability to poll trafficserver's view of the cache volume(s) state (such as a timestamp of when the cache became ready) before or after the cache volumes become available to monitor state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2483) Add 'cache status/readiness' metric to trafficserver
[ https://issues.apache.org/jira/browse/TS-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2483: -- Fix Version/s: (was: 4.2.0) Add 'cache status/readiness' metric to trafficserver Key: TS-2483 URL: https://issues.apache.org/jira/browse/TS-2483 Project: Traffic Server Issue Type: Improvement Components: Cache, Management, Stats Reporter: Ben Haga Assignee: Leif Hedstrom Priority: Minor Fix For: sometime This is a request to add a 'cache readiness' metric (as a time value) to trafficserver. Currently, it is difficult to determine the state of the cache volumes unless trafficserver is configured not to serve traffic until the cache volumes have been brought online. It is desirable to have the ability to poll trafficserver's view of the cache volume(s) state (such as a timestamp of when the cache became ready) before or after the cache volumes become available to monitor state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2483) Add 'cache status/readiness' metric to trafficserver
[ https://issues.apache.org/jira/browse/TS-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869997#comment-13869997 ] ASF subversion and git services commented on TS-2483: - Commit 74763d22dc6ade6aaa978af4273377f29fc4cb41 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=74763d2 ] Revert TS-2483 Add to docs. This reverts commit c89d14621e2fd7ef1350990960f5a33aa3ff06d1. Add 'cache status/readiness' metric to trafficserver Key: TS-2483 URL: https://issues.apache.org/jira/browse/TS-2483 Project: Traffic Server Issue Type: Improvement Components: Cache, Management, Stats Reporter: Ben Haga Assignee: Leif Hedstrom Priority: Minor Fix For: sometime This is a request to add a 'cache readiness' metric (as a time value) to trafficserver. Currently, it is difficult to determine the state of the cache volumes unless trafficserver is configured not to serve traffic until the cache volumes have been brought online. It is desirable to have the ability to poll trafficserver's view of the cache volume(s) state (such as a timestamp of when the cache became ready) before or after the cache volumes become available to monitor state. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870012#comment-13870012 ] James Peach commented on TS-2490: - Yeh, just the latter. traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2437: - Assignee: James Peach James, can you shepherd this through API review process etc.please? If not, return to the pool. Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2437: -- Fix Version/s: 4.2.0 Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Fix For: 4.2.0 Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870186#comment-13870186 ] James Peach commented on TS-2437: - Changes to the public API need to go through the review process described here: https://cwiki.apache.org/confluence/display/TS/API+Review+Process Comments on this proposal: - I'm uncomfortable directly exposing OpenSSL data structures Although the probability of using a different SSL implementation is quite low, it still seems like something we should try hard to avoid. - This creates a dependency from iocore up to the HTTP proxy. - The API itself has a fixed limit on the number of certificates, which won't work. There's no way to determine the number of registered certificates, so the only use case here is to iterate over them all and alter them one at a time. - I think that an API of this nature should be better integrated into the existing Traffic Server API. For example, it would be useful to manipulate the SSL context at session creating time. There's some more ideas for a SSL API in TS-1584 and TS-2210 Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2437) Add an API to expose SSL_CTX for applications
[ https://issues.apache.org/jira/browse/TS-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2437: Component/s: TS API Add an API to expose SSL_CTX for applications - Key: TS-2437 URL: https://issues.apache.org/jira/browse/TS-2437 Project: Traffic Server Issue Type: Task Components: SSL, TS API Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2437.diff It'll be good to add an API to expose all the SSL_CTXs, so that plugins can manipulate their specific ssl settings / call back, etc. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870313#comment-13870313
]
ASF subversion and git services commented on TS-2138:
-
Commit 69d04896ef98ee4f565151fe5b1de6f5328fb5df in branch refs/heads/master
from [~taorui]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=69d0489 ]
TS-2138 TS-2412: fix the bug that cache data loss when restarting
ats if build with linuat native-aio.
Using linux native-AIO, restarting ATS causes complete cache data loss
--
Key: TS-2138
URL: https://issues.apache.org/jira/browse/TS-2138
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: bettydramit
Assignee: weijin
Fix For: 4.2.0
Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
ENV: centos 6 x86_64 gitmaster and
http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
--enable-linux-native-aio --enable-reclaimable-freelist
when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
[ https://issues.apache.org/jira/browse/TS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870315#comment-13870315 ] ASF subversion and git services commented on TS-2412: - Commit 69d04896ef98ee4f565151fe5b1de6f5328fb5df in branch refs/heads/master from [~taorui] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=69d0489 ] TS-2138 TS-2412: fix the bug that cache data loss when restarting ats if build with linuat native-aio. Using linux native-AIO, restarting ATS causes complete cache data loss -- Key: TS-2412 URL: https://issues.apache.org/jira/browse/TS-2412 Project: Traffic Server Issue Type: Sub-task Components: Cache Reporter: weijin Assignee: weijin Fix For: 4.2.0 Attachments: ts-2412.wj.diff -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
[ https://issues.apache.org/jira/browse/TS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-2412. Resolution: Fixed Using linux native-AIO, restarting ATS causes complete cache data loss -- Key: TS-2412 URL: https://issues.apache.org/jira/browse/TS-2412 Project: Traffic Server Issue Type: Sub-task Components: Cache Reporter: weijin Assignee: weijin Fix For: 4.2.0 Attachments: ts-2412.wj.diff -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870348#comment-13870348 ] Yu Qing edited comment on TS-2488 at 1/14/14 3:26 AM: -- sorry, it's my fault! I fixed the bug caused by me. we should revert the temporary patch 283aa3bca9551067c701d0e2fc1d4ebe313e3d1e, then appy my new patch bugfix-for-TS-2488.patch to fix this problem. ps. the output of command make test is all passed, but some cases fail actually. I think this is a bug of Makefile. i 'll report a bug later. was (Author: happy_fish100): sorry, it's my fault! I fixed the bug caused by me. we should revert the temporary patch 283aa3bca9551067c701d0e2fc1d4ebe313e3d1e, then appy my new patch to fix this problem. ps. the output of command make test is all passed, but some cases fail actually. I think this is a bug of Makefile. i 'll report a bug later. any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch, 2488.txt, bugfix-for-TS-2488.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Qing updated TS-2488: Attachment: bugfix-for-TS-2488.patch any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch, 2488.txt, bugfix-for-TS-2488.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870348#comment-13870348 ] Yu Qing edited comment on TS-2488 at 1/14/14 3:28 AM: -- sorry, it's my fault! I fixed the bug caused by me. we should revert the temporary patch 283aa3bca9551067c701d0e2fc1d4ebe313e3d1e, then appy my new patch bugfix-for-TS-2488.patch to fix this problem. ps. the output of command make test is all passed, but some cases fail actually. I think this is a bug of Makefile. i 'll report a bug later. @Kit Chan thank you, I am sorry again. was (Author: happy_fish100): sorry, it's my fault! I fixed the bug caused by me. we should revert the temporary patch 283aa3bca9551067c701d0e2fc1d4ebe313e3d1e, then appy my new patch bugfix-for-TS-2488.patch to fix this problem. ps. the output of command make test is all passed, but some cases fail actually. I think this is a bug of Makefile. i 'll report a bug later. any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch, 2488.txt, bugfix-for-TS-2488.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2491) esi make test outputs All tests passed! but some test cases fail
Yu Qing created TS-2491: --- Summary: esi make test outputs All tests passed! but some test cases fail Key: TS-2491 URL: https://issues.apache.org/jira/browse/TS-2491 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Yu Qing when some test cases fail in test/parser_test.cc, the last line is All tests passed!. we should show the error message when a test case fails, and break the batch tests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2492) traffic_line command to synchronize configuration
James Peach created TS-2492:
---
Summary: traffic_line command to synchronize configuration
Key: TS-2492
URL: https://issues.apache.org/jira/browse/TS-2492
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: James Peach
In integration testing and possibly also in deployment configuration, you might
need to use {{traffic_line}} to make a config change, then restart. This can
fail if you restart before the configuration change it written out.
It would be helpful if there was a synchronous {{traffic_line}} command that
flushed the configuration.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-1467) Do something about client initiated renegotiation (SSL) DDoS
[ https://issues.apache.org/jira/browse/TS-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-1467: --- Fix Version/s: (was: 5.0.0) 4.2.0 Do something about client initiated renegotiation (SSL) DDoS Key: TS-1467 URL: https://issues.apache.org/jira/browse/TS-1467 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Leif Hedstrom Assignee: Bryan Call Fix For: 4.2.0 https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (TS-1467) Do something about client initiated renegotiation (SSL) DDoS
[ https://issues.apache.org/jira/browse/TS-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1467: --- Assignee: Bryan Call (was: Phil Sorber) Over to Bryan. Do something about client initiated renegotiation (SSL) DDoS Key: TS-1467 URL: https://issues.apache.org/jira/browse/TS-1467 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Leif Hedstrom Assignee: Bryan Call Fix For: 5.0.0 https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1821) AIO tests don't build with native AIO
[ https://issues.apache.org/jira/browse/TS-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870423#comment-13870423 ] ASF subversion and git services commented on TS-1821: - Commit 805c1feab432f8cd0948aeddc7d9778fd357ce73 in branch refs/heads/master from [~taorui] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=805c1fe ] TS-1821 to make the AIO test pass when build with native AIO AIO tests don't build with native AIO - Key: TS-1821 URL: https://issues.apache.org/jira/browse/TS-1821 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: weijin Fix For: 5.0.0 Attachments: ts-1821.wj.diff /opt/src/trafficserver.git/configure --prefix=/opt/ats --enable-linux-native-aio make -j 4 make check test_AIO-test_AIO.o: In function `main': /opt/src/trafficserver.git/iocore/aio/test_AIO.cc:498: undefined reference to `cache_config_threads_per_disk' collect2: error: ld returned 1 exit status -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1821) AIO tests don't build with native AIO
[ https://issues.apache.org/jira/browse/TS-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-1821. Resolution: Fixed AIO tests don't build with native AIO - Key: TS-1821 URL: https://issues.apache.org/jira/browse/TS-1821 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: weijin Fix For: 5.0.0 Attachments: ts-1821.wj.diff /opt/src/trafficserver.git/configure --prefix=/opt/ats --enable-linux-native-aio make -j 4 make check test_AIO-test_AIO.o: In function `main': /opt/src/trafficserver.git/iocore/aio/test_AIO.cc:498: undefined reference to `cache_config_threads_per_disk' collect2: error: ld returned 1 exit status -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870429#comment-13870429
]
weijin commented on TS-2205:
It maybe related to TS-2027, so we can close this now, reopen it if arise
again.
AIO caused system hang
--
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.1
Reporter: Zhao Yongming
Assignee: weijin
Priority: Critical
Fix For: 4.2.0
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin closed TS-2205.
--
Resolution: Fixed
AIO caused system hang
--
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.1
Reporter: Zhao Yongming
Assignee: weijin
Priority: Critical
Fix For: 4.2.0
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-656) reimplement Connection Collapsing in a smooth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870438#comment-13870438 ] weijin commented on TS-656: --- I`ll focus on this project in the next few weeks, maybe months. reimplement Connection Collapsing in a smooth way - Key: TS-656 URL: https://issues.apache.org/jira/browse/TS-656 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 2.1.6 Environment: per discussed in IRC, we'd like to clean the current CC codes from trunk. Reporter: Zhao Yongming Assignee: weijin Fix For: 6.0.0 we should figure out how to implement the Connection Collapsing that not so ugly. target for V3.1 or so. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1311) Range hit in cluster will crash server
[
https://issues.apache.org/jira/browse/TS-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming resolved TS-1311.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: 5.0.0)
I don't think the current master have trouble with cluster crashing now, open
new thread if we meet
Range hit in cluster will crash server
--
Key: TS-1311
URL: https://issues.apache.org/jira/browse/TS-1311
Project: Traffic Server
Issue Type: Bug
Components: Clustering, HTTP, Network
Affects Versions: 3.3.0, 3.2.0
Environment: cluster type 1, and range request hit, where the content
is on the other hosts.
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Labels: Crash
with the changes in TS-475, the single ranged request will be handled by
tunnel and pread. while this will crash in cluster env:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x309f00f4a0]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x188)[0x555668]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x5554cd]
/usr/bin/traffic_server[0x63fdab]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x353)[0x643a13]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x63befe]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x660a74]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x661403]
/usr/bin/traffic_server[0x65fd82]
/lib64/libpthread.so.0[0x309f0077f1]
/lib64/libc.so.6(clone+0x6d)[0x309ece570d]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-910) log collation in custom log will make dedicate connection to the same collation server
[ https://issues.apache.org/jira/browse/TS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-910: - Priority: Trivial (was: Major) Issue Type: Improvement (was: Bug) log collation in custom log will make dedicate connection to the same collation server -- Key: TS-910 URL: https://issues.apache.org/jira/browse/TS-910 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 3.1.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Trivial Fix For: sometime when you define LogObject in logs_xml.config, and set CollationHosts, it will open connections for each LogObject, despite you put the same host in CollationHosts. it will affect the default squid logging too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2488) any of the space chars can follow the esi starting tags
[ https://issues.apache.org/jira/browse/TS-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13870492#comment-13870492 ] Kit Chan commented on TS-2488: -- Thanks. It works well. I am wondering whether we can do better to keep test 42 of parser_test unchanged. May be some special includes implementation may rely on that. I think commenting out line 331 in the final version of lib/EsiParser.cc will do the job. I think it won't make a difference in other execution paths which it is shown to keep all unit tests passed. What do you think? Thanks. any of the space chars can follow the esi starting tags --- Key: TS-2488 URL: https://issues.apache.org/jira/browse/TS-2488 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Yu Qing Assignee: Kit Chan Attachments: 0001-TS-2488-any-space-char-can-follow-the-esi-starting-t.patch, 2488.txt, bugfix-for-TS-2488.patch only the space char ' ' can follow the esi starting tags such as esi:include, !--esi now, we should allow any space char after these tags. the space chars include: ' ', '\t', '\r' and '\n'. for example, following common usage: !--esi esi bala bala ... -- because no space after the !--esi, the esi parser will keep these tags which should be removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
