[jira] [Comment Edited] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757477#comment-13757477
]
Yunkai Zhang edited comment on TS-2174 at 9/4/13 6:05 AM:
--
[~seri]:
There is another reason to cause Transaction Per Second Value to 0.
stats.config.xml was modified incorrectly by this commit: 4bc71fe7, TS-443.
I'll open a new ticket(TS-2175) to fix it.
was (Author: yunkai):
[~seri]:
There is another reason to cause Transaction Per Second Value to 0.
stats.config.xml was modified incorrectly by this commit: 4bc71fe7, TS-443.
I'll open a new ticket to fix it.
traffic_shell/traffic_line miss some stats value
Key: TS-2174
URL: https://issues.apache.org/jira/browse/TS-2174
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.1.0
Attachments: 0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
I'm sorry for too late to fix this bug.
Here is an example about the broken of traffic_shell(reported by
Esmqe...@163.com ):
{code}
echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
Successfully Initialized MgmtAPI in
/usr/local/trafficserver-4.0.1/var/trafficserver
trafficserver
Document Hit Rate 0.00 %*
Ram cache Hit Rate --- 0.00 %*
Bandwidth Saving - 0.00 %*
Cache Percent Free --- 0.00 %
Open Server Connections -- 473
Open Client Connections -- 3796
Open Cache Connections --- 1
Client Throughput 18.100512 MBit/Sec
Transaction Per Second --- 0.00
{code}
The root cause is that StatBinaryEval() use RecInt type to hold the result of
*div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Deleted] (TS-2175) stats.config.xml was broken by TS-443
[
https://issues.apache.org/jira/browse/TS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang deleted TS-2175:
-
stats.config.xml was broken by TS-443
-
Key: TS-2175
URL: https://issues.apache.org/jira/browse/TS-2175
Project: Traffic Server
Issue Type: Bug
Reporter: Yunkai Zhang
stats.config.xml was broken by TS-443.
It's no meaningful to do *recursive* calculation:
{code}
statistics
minimum=0
interval=10
destinationproxy.node.user_agent_xacts_per_second/destination
destination
scope=clusterproxy.cluster.user_agent_xacts_per_second/destination
expression
proxy.node.http.user_agent_xacts_per_second
/expression
/statistics
{code}
The *expression*, proxy.node.http.user_agent_xacts_per_second, equals to node
*destination*, that is wrong.
This issue will cause the value of
proxy.node.http.user_agent_xacts_per_second to be zero.
There are other same mistakes caused by TS-443.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Updated] (TS-2175) stats.config.xml was broken by TS-443
On Wed, Sep 4, 2013 at 1:55 PM, Leif Hedstrom (JIRA) j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/TS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Leif Hedstrom updated TS-2175:
--
Backport to Version: 4.0.2
Fanstastic… Good find!
stats.config.xml was broken by TS-443
-
Key: TS-2175
URL: https://issues.apache.org/jira/browse/TS-2175
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Yunkai Zhang
Fix For: 4.1.0
stats.config.xml was broken by TS-443.
It's no meaningful to do *recursive* calculation:
{code}
statistics
minimum=0
interval=10
destinationproxy.node.user_agent_xacts_per_second/destination
destination
scope=clusterproxy.cluster.user_agent_xacts_per_second/destination
expression
proxy.node.http.user_agent_xacts_per_second
/expression
/statistics
{code}
I looked in wrong, proxy.node.http.user_agent_xacts_per_second !=
proxy.node.user_agent_xacts_per_second,
sorry for noise.
I'll delete this ticket.
The *expression*, proxy.node.http.user_agent_xacts_per_second, equals to
node *destination*, that is wrong.
This issue will cause the value of
proxy.node.http.user_agent_xacts_per_second to be zero.
There are other same mistakes caused by TS-443.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Yunkai Zhang
Work at Taobao
[jira] [Commented] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757721#comment-13757721
]
Leif Hedstrom commented on TS-2107:
---
I'm backing this out right now. One question:
I see a few changes that looks like the might have been useful, such as
canceling some event. Should those go in as fixes for something else?
add absolute proxy.config.http.transaction_active_timeout_in about request
---
Key: TS-2107
URL: https://issues.apache.org/jira/browse/TS-2107
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Affects Versions: 3.3.5
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 5.0.0
Attachments: TS-2107.patch
Now, ts use proxy.config.http.transaction_active_timeout_in handle request
and response transaction. But in some very bad network, we catch some log
that it cost 30s to get ua_read_header_done, that is unacceptable, should be
controled with some dedicated timeout in records.config.
we world prefer to add proxy.config.http.transaction_header_timeout_in
proxy.config.http.transaction_request_timeout_in
{code}
[Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
ua_read_header_done: 46.790 cache_open_read_begin: 46.790
cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757723#comment-13757723
]
Leif Hedstrom commented on TS-2107:
---
Also, this looks a potential bug, it could trigger if the configuration is
changed and reloaded dynamically:
{code}
+ // is setted HttpConfig::m_master.transaction_header_active_timeout_in,
so should reset active_timeout_in
+ if (ua_session-get_netvc()-get_active_timeout() ==
HRTIME_SECONDS(HttpConfig::m_master.transaction_header_active_timeout_in)) {
{code}
If the config changes, this comparison might not be true any more. It feels
that the netvc needs to know which of the two potential active timeout states
it is actually in.
add absolute proxy.config.http.transaction_active_timeout_in about request
---
Key: TS-2107
URL: https://issues.apache.org/jira/browse/TS-2107
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Affects Versions: 3.3.5
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 5.0.0
Attachments: TS-2107.patch
Now, ts use proxy.config.http.transaction_active_timeout_in handle request
and response transaction. But in some very bad network, we catch some log
that it cost 30s to get ua_read_header_done, that is unacceptable, should be
controled with some dedicated timeout in records.config.
we world prefer to add proxy.config.http.transaction_header_timeout_in
proxy.config.http.transaction_request_timeout_in
{code}
[Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
ua_read_header_done: 46.790 cache_open_read_begin: 46.790
cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2172) Explicitly use subdir-objects in automake init
[ https://issues.apache.org/jira/browse/TS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757755#comment-13757755 ] Leif Hedstrom commented on TS-2172: --- I also think this breaks out-of-source builds. At least I can not get that to work anymore, on any platform. Please fix or revert ASAP. Explicitly use subdir-objects in automake init -- Key: TS-2172 URL: https://issues.apache.org/jira/browse/TS-2172 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Li-Wen Hsu Assignee: Yunkai Zhang Fix For: 4.1.0 This avoids warnings from automake 1.14: warning: source file 'foo/bar.c' is in a subdirectory, but option 'subdir-objects' is disabled and generates correct configure script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TS-2172) Explicitly use subdir-objects in automake init
[ https://issues.apache.org/jira/browse/TS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reopened TS-2172: --- Explicitly use subdir-objects in automake init -- Key: TS-2172 URL: https://issues.apache.org/jira/browse/TS-2172 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Li-Wen Hsu Assignee: Yunkai Zhang Fix For: 4.1.0 This avoids warnings from automake 1.14: warning: source file 'foo/bar.c' is in a subdirectory, but option 'subdir-objects' is disabled and generates correct configure script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757759#comment-13757759
]
Leif Hedstrom commented on TS-2107:
---
One more question:
This code looks like it was adding a new functionality, removing a timeout
where we did not before. Should this be added back after I revert? Please take
a look at the revert I had to do as well.
{code}
@@ -3268,6 +3289,7 @@ HttpSM::tunnel_handler_post_ua(int event,
HttpTunnelProducer * p)
case VC_EVENT_ACTIVE_TIMEOUT:
// Did not complete post tunnling. Abort the
// server and close the ua
+ua_session-get_netvc()-cancel_active_timeout();
p-handler_state = HTTP_SM_POST_UA_FAIL;
tunnel.chain_abort_all(p);
p-read_vio = NULL;
@@ -3297,6 +3319,7 @@ HttpSM::tunnel_handler_post_ua(int event,
HttpTunnelProducer * p)
p-handler_state = HTTP_SM_POST_SUCCESS;
p-read_success = true;
ua_entry-in_tunnel = false;
+ua_session-get_netvc()-cancel_active_timeout();
if (p-do_dechunking || p-do_chunked_passthru) {
if (p-chunked_handler.truncation) {
{code}
add absolute proxy.config.http.transaction_active_timeout_in about request
---
Key: TS-2107
URL: https://issues.apache.org/jira/browse/TS-2107
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Affects Versions: 3.3.5
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 5.0.0
Attachments: TS-2107.patch
Now, ts use proxy.config.http.transaction_active_timeout_in handle request
and response transaction. But in some very bad network, we catch some log
that it cost 30s to get ua_read_header_done, that is unacceptable, should be
controled with some dedicated timeout in records.config.
we world prefer to add proxy.config.http.transaction_header_timeout_in
proxy.config.http.transaction_request_timeout_in
{code}
[Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
ua_read_header_done: 46.790 cache_open_read_begin: 46.790
cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757763#comment-13757763
]
ASF subversion and git services commented on TS-2107:
-
Commit c05a09799488bd91a9d6186535bf2f2796c5877d in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c05a097 ]
TS-2107 Revert this change, please review for correctness
add absolute proxy.config.http.transaction_active_timeout_in about request
---
Key: TS-2107
URL: https://issues.apache.org/jira/browse/TS-2107
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Affects Versions: 3.3.5
Reporter: Bin Chen
Assignee: Bin Chen
Fix For: 5.0.0
Attachments: TS-2107.patch
Now, ts use proxy.config.http.transaction_active_timeout_in handle request
and response transaction. But in some very bad network, we catch some log
that it cost 30s to get ua_read_header_done, that is unacceptable, should be
controled with some dedicated timeout in records.config.
we world prefer to add proxy.config.http.transaction_header_timeout_in
proxy.config.http.transaction_request_timeout_in
{code}
[Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
ua_read_header_done: 46.790 cache_open_read_begin: 46.790
cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2068) Add subdir-objects to configure.ac
[ https://issues.apache.org/jira/browse/TS-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2068. --- Resolution: Duplicate Marking as dupe, since work is done on TS-2172. Add subdir-objects to configure.ac -- Key: TS-2068 URL: https://issues.apache.org/jira/browse/TS-2068 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Fix For: 4.1.0 New versions of automake needs it, however, it seems to fail with automake on RHEL5. How can we make this conditional on automake version? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2178) Transparent proxy should check for connection: close when use_cleitn_source_port is enabled.
[ https://issues.apache.org/jira/browse/TS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2178: Priority: Minor (was: Major) Transparent proxy should check for connection: close when use_cleitn_source_port is enabled. Key: TS-2178 URL: https://issues.apache.org/jira/browse/TS-2178 Project: Traffic Server Issue Type: Bug Components: TProxy Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor There are issues with keep alive and use client target address port. if the server closes such a connection, the client connection should also be closed. If, in such a case, the server sends Connection: close then ATS should disable keep alive on the client side and close the connection after the response has been sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2177) FeatureAPIHooks code needs better comments, naming.
[ https://issues.apache.org/jira/browse/TS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2177: Fix Version/s: (was: 4.0.2) 4.1.0 FeatureAPIHooks code needs better comments, naming. --- Key: TS-2177 URL: https://issues.apache.org/jira/browse/TS-2177 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 4.1.0 Add comments to the FeatureAPIHook code. Rename template parameter MAX_ID to N so the name corresponds to the use of the parameter. Add a couple of utility methods for future use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1424) Transparent proxy with proxy.config.http.use_client_source_port==1 has problems if the client is keep-alive and the origin server is not.
[ https://issues.apache.org/jira/browse/TS-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757975#comment-13757975 ] Alan M. Carroll commented on TS-1424: - I haven't had time to look at this. Currently I think it's working well enough, but I would like to explore Roland's comment in the future so will file a new bug to track that. Transparent proxy with proxy.config.http.use_client_source_port==1 has problems if the client is keep-alive and the origin server is not. - Key: TS-1424 URL: https://issues.apache.org/jira/browse/TS-1424 Project: Traffic Server Issue Type: Bug Environment: 3.2 with transparent (TProxy) interception + proxy.config.http.use_client_source_port = 1 Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 4.1.0 Attachments: traffic.rar, ts-1424-3-2-x.diff As keep-alive is hop-to-hop ATS will happily support client keep-alive in instances where an Origin Server terminates the connection after each transaction. However, when using proxy.config.http.use_client_source_port this behavior can cause some sites to break. When the client is kept alive, subsequent requests are made rapidly and with the same 4-tuple for addressing. Since ATS is trying to match the 4-tuple (due to proxy.config.http.use_client_source_port) it enters a 3-way race between: # the FIN, FIN/ACK packets being exchanged with the origin server and the new request packets from the client. If the OS is slow it is possible that ATS will attempt to reconnect with the same port/address before the connection is legitimately closed. # Kernel timers for PAWS and recently closed sockets. This is different (and much shorter) than the time-wait state and there is no way to disable it # Everything working out just fine and the connection establishing like normal The best repro case I've seen is a slow origin server that serves pages in frame tags from the same host but does not support keep-alive (http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp for instance) It is possible that simply respecting a servers keep-alive settings when using proxy.config.http.use_client_source_port would work as the original client would change the 4-tuple address for its next connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-965: - Fix Version/s: (was: 4.2.0) 4.1.0 cache.config can't deal with both revalidate= and ttl-in-cache= specified - Key: TS-965 URL: https://issues.apache.org/jira/browse/TS-965 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Labels: A Fix For: 4.1.0 If both of these options are specified (with the same time?), nothing is cached at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757974#comment-13757974 ] Leif Hedstrom commented on TS-965: -- We should investigate this for v4.1.0 cache.config can't deal with both revalidate= and ttl-in-cache= specified - Key: TS-965 URL: https://issues.apache.org/jira/browse/TS-965 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Labels: A Fix For: 4.1.0 If both of these options are specified (with the same time?), nothing is cached at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2178) Transparent proxy should check for connection: close when use_cleitn_source_port is enabled.
[ https://issues.apache.org/jira/browse/TS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2178: --- Assignee: Alan M. Carroll Transparent proxy should check for connection: close when use_cleitn_source_port is enabled. Key: TS-2178 URL: https://issues.apache.org/jira/browse/TS-2178 Project: Traffic Server Issue Type: Bug Components: TProxy Reporter: Alan M. Carroll Assignee: Alan M. Carroll There are issues with keep alive and use client target address port. if the server closes such a connection, the client connection should also be closed. If, in such a case, the server sends Connection: close then ATS should disable keep alive on the client side and close the connection after the response has been sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2178) Transparent proxy should check for connection: close when use_cleitn_source_port is enabled.
Alan M. Carroll created TS-2178: --- Summary: Transparent proxy should check for connection: close when use_cleitn_source_port is enabled. Key: TS-2178 URL: https://issues.apache.org/jira/browse/TS-2178 Project: Traffic Server Issue Type: Bug Components: TProxy Reporter: Alan M. Carroll There are issues with keep alive and use client target address port. if the server closes such a connection, the client connection should also be closed. If, in such a case, the server sends Connection: close then ATS should disable keep alive on the client side and close the connection after the response has been sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2176) TSHttpTxnCacheLookupSkip doesn't work
[
https://issues.apache.org/jira/browse/TS-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2176:
--
Fix Version/s: 4.1.0
James: Would you like to take this? I think the patch looks reasonable, but I
think you had some use cases around this API, so maybe you can test / verify ?
TSHttpTxnCacheLookupSkip doesn't work
-
Key: TS-2176
URL: https://issues.apache.org/jira/browse/TS-2176
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Corey Cossentino
Fix For: 4.1.0
Attachments: ts2176_api_skip_cache_lookup.patch
When {{is_request_cache_lookupable}} reads the value of
{{api_skip_cache_lookup}} it also resets the value to false.
Since the function is called from {{HandleRequest}}, the flag set by the API
call will be ignored by {{DecideCacheLookup}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2176) TSHttpTxnCacheLookupSkip doesn't work
Corey Cossentino created TS-2176:
Summary: TSHttpTxnCacheLookupSkip doesn't work
Key: TS-2176
URL: https://issues.apache.org/jira/browse/TS-2176
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Corey Cossentino
When {{is_request_cache_lookupable}} reads the value of
{{api_skip_cache_lookup}} it also resets the value to false.
Since the function is called from {{HandleRequest}}, the flag set by the API
call will be ignored by {{DecideCacheLookup}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2176) TSHttpTxnCacheLookupSkip doesn't work
[
https://issues.apache.org/jira/browse/TS-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Corey Cossentino updated TS-2176:
-
Attachment: ts2176_api_skip_cache_lookup.patch
TSHttpTxnCacheLookupSkip doesn't work
-
Key: TS-2176
URL: https://issues.apache.org/jira/browse/TS-2176
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Corey Cossentino
Attachments: ts2176_api_skip_cache_lookup.patch
When {{is_request_cache_lookupable}} reads the value of
{{api_skip_cache_lookup}} it also resets the value to false.
Since the function is called from {{HandleRequest}}, the flag set by the API
call will be ignored by {{DecideCacheLookup}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2177) FeatureAPIHooks code needs better comments, naming.
Alan M. Carroll created TS-2177: --- Summary: FeatureAPIHooks code needs better comments, naming. Key: TS-2177 URL: https://issues.apache.org/jira/browse/TS-2177 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Alan M. Carroll Add comments to the FeatureAPIHook code. Rename template parameter MAX_ID to N so the name corresponds to the use of the parameter. Add a couple of utility methods for future use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2177) FeatureAPIHooks code needs better comments, naming.
[ https://issues.apache.org/jira/browse/TS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13757965#comment-13757965 ] ASF subversion and git services commented on TS-2177: - Commit 0ec6fc7e12f79f84fa284015493dfc92f1ca5413 in branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0ec6fc7 ] TS-2177: Improve code quality of FeatureAPIHooks. FeatureAPIHooks code needs better comments, naming. --- Key: TS-2177 URL: https://issues.apache.org/jira/browse/TS-2177 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Alan M. Carroll Add comments to the FeatureAPIHook code. Rename template parameter MAX_ID to N so the name corresponds to the use of the parameter. Add a couple of utility methods for future use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2177) FeatureAPIHooks code needs better comments, naming.
[ https://issues.apache.org/jira/browse/TS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2177. - Resolution: Fixed Fix Version/s: 4.0.2 Assignee: Alan M. Carroll FeatureAPIHooks code needs better comments, naming. --- Key: TS-2177 URL: https://issues.apache.org/jira/browse/TS-2177 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 4.0.2 Add comments to the FeatureAPIHook code. Rename template parameter MAX_ID to N so the name corresponds to the use of the parameter. Add a couple of utility methods for future use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2105) Barcamp in Beijing
[ https://issues.apache.org/jira/browse/TS-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2105. --- Resolution: Invalid Barcamp in Beijing -- Key: TS-2105 URL: https://issues.apache.org/jira/browse/TS-2105 Project: Traffic Server Issue Type: Improvement Components: Community Reporter: Igor Galić We'd like to hold a Bar Camp in Beijing in early/mid October. Good times seems to be October 9 - October 15, or otherwise, October 16 - 22. Many of our core-developers are very interested and we hope just as many from our community are, to make this event happen! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2169) SSL statistics
[ https://issues.apache.org/jira/browse/TS-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2169: -- Fix Version/s: 4.2.0 SSL statistics -- Key: TS-2169 URL: https://issues.apache.org/jira/browse/TS-2169 Project: Traffic Server Issue Type: Wish Components: SSL, Stats Reporter: David Carlin Fix For: 4.2.0 It would be swell if there were some traffic_line SSL statistic variables. For instance, number of SSL connections and SSL bytes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2169) SSL statistics
[ https://issues.apache.org/jira/browse/TS-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758042#comment-13758042 ] Leif Hedstrom commented on TS-2169: --- Marking as 4.2.0 for now, please move / assign as someone plan working on this. SSL statistics -- Key: TS-2169 URL: https://issues.apache.org/jira/browse/TS-2169 Project: Traffic Server Issue Type: Wish Components: SSL, Stats Reporter: David Carlin Fix For: 4.2.0 It would be swell if there were some traffic_line SSL statistic variables. For instance, number of SSL connections and SSL bytes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2144) traffic_server crashes when clearing cache
[
https://issues.apache.org/jira/browse/TS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2144:
--
Fix Version/s: 5.0.0
traffic_server crashes when clearing cache
--
Key: TS-2144
URL: https://issues.apache.org/jira/browse/TS-2144
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: David Carlin
Priority: Minor
Fix For: 5.0.0
I've been clearing the cache on a few non production hosts more often than
usual to test some config/plugin changes. Running traffic_server -Cclear
after stopping ATS occasionally results in the following. Running it again
will clear the cache.
{noformat}
# traffic_server -Cclear
[TrafficServer] using root directory '/home/y'
*** glibc detected *** traffic_server: realloc(): invalid pointer:
0x7f593f432010 ***
=== Backtrace: =
/lib64/libc.so.6[0x3895e753c6]
/lib64/libc.so.6(realloc+0x2e2)[0x3895e7b182]
/home/y/lib64/libtsutil.so.3(ats_realloc+0x9)[0x7f5942d4df19]
traffic_server(_Z25RecMessageMarshal_ReallocP13RecMessageHdrPK9RecRecord+0x97)[0x699177]
traffic_server(_Z17send_push_messagev+0x8b)[0x69599b]
traffic_server(_ZN9sync_cont4syncEiP5Event+0x3b)[0x69aceb]
traffic_server(_ZN7EThread7executeEv+0xc90)[0x6a4100]
traffic_server[0x6a1dca]
/lib64/libpthread.so.0(+0x3896207851)[0x7f5942554851]
/lib64/libc.so.6(clone+0x6d)[0x3895ee76dd]
=== Memory map:
0040-0075 r-xp fd:00 2795238
/home/y/bin64/traffic_server
0094f000-00963000 rw-p 0034f000 fd:00 2795238
/home/y/bin64/traffic_server
00963000-00f5b000 rw-p 00:00 0
012c6000-013e7000 rw-p 00:00 0
[heap]
3036a0-3036a15000 r-xp fd:01 238064
/lib64/libz.so.1.2.3
3036a15000-3036c14000 ---p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036c14000-3036c15000 r--p 00014000 fd:01 238064
/lib64/libz.so.1.2.3
3036c15000-3036c16000 rw-p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036e0-3036f73000 r-xp fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3036f73000-3037173000 ---p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037173000-303718c000 r--p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
303718c000-3037196000 rw-p 0018c000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037196000-303719a000 rw-p 00:00 0
303760-3037747000 r-xp fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037747000-3037946000 ---p 00147000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037946000-303795 rw-p 00146000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
303795-3037951000 rw-p 00:00 0
3037a0-3037a27000 r-xp fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037a27000-3037c27000 ---p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037c27000-3037c28000 rw-p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
389560-389562 r-xp fd:01 238023
/lib64/ld-2.12.so
389581f000-389582 r--p 0001f000 fd:01 238023
/lib64/ld-2.12.so
389582-3895821000 rw-p 0002 fd:01 238023
/lib64/ld-2.12.so
3895821000-3895822000 rw-p 00:00 0
3895a0-3895a02000 r-xp fd:01 238026
/lib64/libdl-2.12.so
3895a02000-3895c02000 ---p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c02000-3895c03000 r--p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c03000-3895c04000 rw-p 3000 fd:01 238026
/lib64/libdl-2.12.so
3895e0-3895f89000 r-xp fd:01 238024
/lib64/libc-2.12.so
3895f89000-3896188000 ---p 00189000 fd:01 238024
/lib64/libc-2.12.so
3896188000-389618c000 r--p 00188000 fd:01 238024
/lib64/libc-2.12.so
389618c000-389618d000 rw-p 0018c000 fd:01 238024
/lib64/libc-2.12.so
389618d000-3896192000 rw-p 00:00 0
389620-3896319000 r-xp fd:01 53667
/usr/lib64/libtcl8.5.so
3896319000-3896519000 ---p 00119000 fd:01 53667
/usr/lib64/libtcl8.5.so
3896519000-3896529000 rw-p 00119000 fd:01 53667
/usr/lib64/libtcl8.5.so
3896a0-3896a83000 r-xp fd:01 238032
[jira] [Updated] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2166:
--
Fix Version/s: 4.2.0
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.4, 4.2.0
Reporter: portl4t
Fix For: 4.2.0
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758045#comment-13758045
]
Leif Hedstrom commented on TS-2166:
---
Edit, there's a similar issue in TS-1106, where multiple Via: headers are added.
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.4
Reporter: portl4t
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2166:
--
Affects Version/s: 4.2.0
Marking as v4.2.0 for now, please please move / assign as appropriate.
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.4, 4.2.0
Reporter: portl4t
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2157) Replace addr with appropriate src_addr and dst_addr in ConnectionAttributes
[ https://issues.apache.org/jira/browse/TS-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2157: -- Fix Version/s: 5.0.0 Replace addr with appropriate src_addr and dst_addr in ConnectionAttributes - Key: TS-2157 URL: https://issues.apache.org/jira/browse/TS-2157 Project: Traffic Server Issue Type: New Feature Components: Network Reporter: Leif Hedstrom Fix For: 5.0.0 This would more clearly let us encapsulate the two endpoint's (IpEndpoint) for each connection. In addition, we ought to be able to remove the port member from ConnectionAttributes as well, and its convoluted and overloaded semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the port information as necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2144) traffic_server crashes when clearing cache
[
https://issues.apache.org/jira/browse/TS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758049#comment-13758049
]
Leif Hedstrom commented on TS-2144:
---
marking as 5.0.0 for now, move as appropriate.
traffic_server crashes when clearing cache
--
Key: TS-2144
URL: https://issues.apache.org/jira/browse/TS-2144
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: David Carlin
Priority: Minor
Fix For: 5.0.0
I've been clearing the cache on a few non production hosts more often than
usual to test some config/plugin changes. Running traffic_server -Cclear
after stopping ATS occasionally results in the following. Running it again
will clear the cache.
{noformat}
# traffic_server -Cclear
[TrafficServer] using root directory '/home/y'
*** glibc detected *** traffic_server: realloc(): invalid pointer:
0x7f593f432010 ***
=== Backtrace: =
/lib64/libc.so.6[0x3895e753c6]
/lib64/libc.so.6(realloc+0x2e2)[0x3895e7b182]
/home/y/lib64/libtsutil.so.3(ats_realloc+0x9)[0x7f5942d4df19]
traffic_server(_Z25RecMessageMarshal_ReallocP13RecMessageHdrPK9RecRecord+0x97)[0x699177]
traffic_server(_Z17send_push_messagev+0x8b)[0x69599b]
traffic_server(_ZN9sync_cont4syncEiP5Event+0x3b)[0x69aceb]
traffic_server(_ZN7EThread7executeEv+0xc90)[0x6a4100]
traffic_server[0x6a1dca]
/lib64/libpthread.so.0(+0x3896207851)[0x7f5942554851]
/lib64/libc.so.6(clone+0x6d)[0x3895ee76dd]
=== Memory map:
0040-0075 r-xp fd:00 2795238
/home/y/bin64/traffic_server
0094f000-00963000 rw-p 0034f000 fd:00 2795238
/home/y/bin64/traffic_server
00963000-00f5b000 rw-p 00:00 0
012c6000-013e7000 rw-p 00:00 0
[heap]
3036a0-3036a15000 r-xp fd:01 238064
/lib64/libz.so.1.2.3
3036a15000-3036c14000 ---p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036c14000-3036c15000 r--p 00014000 fd:01 238064
/lib64/libz.so.1.2.3
3036c15000-3036c16000 rw-p 00015000 fd:01 238064
/lib64/libz.so.1.2.3
3036e0-3036f73000 r-xp fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3036f73000-3037173000 ---p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037173000-303718c000 r--p 00173000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
303718c000-3037196000 rw-p 0018c000 fd:01 53888
/usr/lib64/libcrypto.so.1.0.0
3037196000-303719a000 rw-p 00:00 0
303760-3037747000 r-xp fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037747000-3037946000 ---p 00147000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
3037946000-303795 rw-p 00146000 fd:01 53581
/usr/lib64/libxml2.so.2.7.6
303795-3037951000 rw-p 00:00 0
3037a0-3037a27000 r-xp fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037a27000-3037c27000 ---p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
3037c27000-3037c28000 rw-p 00027000 fd:01 49878
/usr/lib64/libhwloc.so.5.1.0
389560-389562 r-xp fd:01 238023
/lib64/ld-2.12.so
389581f000-389582 r--p 0001f000 fd:01 238023
/lib64/ld-2.12.so
389582-3895821000 rw-p 0002 fd:01 238023
/lib64/ld-2.12.so
3895821000-3895822000 rw-p 00:00 0
3895a0-3895a02000 r-xp fd:01 238026
/lib64/libdl-2.12.so
3895a02000-3895c02000 ---p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c02000-3895c03000 r--p 2000 fd:01 238026
/lib64/libdl-2.12.so
3895c03000-3895c04000 rw-p 3000 fd:01 238026
/lib64/libdl-2.12.so
3895e0-3895f89000 r-xp fd:01 238024
/lib64/libc-2.12.so
3895f89000-3896188000 ---p 00189000 fd:01 238024
/lib64/libc-2.12.so
3896188000-389618c000 r--p 00188000 fd:01 238024
/lib64/libc-2.12.so
389618c000-389618d000 rw-p 0018c000 fd:01 238024
/lib64/libc-2.12.so
389618d000-3896192000 rw-p 00:00 0
389620-3896319000 r-xp fd:01 53667
/usr/lib64/libtcl8.5.so
3896319000-3896519000 ---p 00119000 fd:01 53667
/usr/lib64/libtcl8.5.so
3896519000-3896529000 rw-p 00119000 fd:01 53667
[jira] [Assigned] (TS-2151) Do we really need HttpSM::_instantiate_func() now?
[
https://issues.apache.org/jira/browse/TS-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2151:
-
Assignee: Leif Hedstrom
Do we really need HttpSM::_instantiate_func() now?
--
Key: TS-2151
URL: https://issues.apache.org/jira/browse/TS-2151
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
The HttpSM implements the instantiate_func() which means the Sparse Class
allocator ends up trying to optimize the memcpy(). We should benchmark
this, and see if is actually a performance improvement still. Simplifying
this code with just a mempcy() (i.e. use normal class allocator behavior)
would make it safer and less confusing.
{code}
void
HttpSM::_instantiate_func(HttpSM * prototype, HttpSM * new_instance)
{
int history_len = sizeof(prototype-history);
int total_len = sizeof(HttpSM);
int pre_history_len = (char *) ((prototype-history)) - (char *) prototype;
int post_history_len = total_len - history_len - pre_history_len;
int post_offset = pre_history_len + history_len;
#ifndef SIMPLE_MEMCPY_INIT
int j;
memset(((char *) new_instance), 0, pre_history_len);
memset(((char *) new_instance) + post_offset, 0, post_history_len);
uint32_t *pd = (uint32_t *) new_instance;
for (j = 0; j scat_count; j++) {
pd[to[j]] = val[j];
}
ink_assert((memcmp((char *) new_instance, (char *) prototype,
pre_history_len) == 0)
(memcmp(((char *) new_instance) + post_offset, ((char *)
prototype) + post_offset, post_history_len) == 0));
#else
// memcpy(new_instance, prototype, total_len);
memcpy(new_instance, prototype, pre_history_len);
memcpy(((char *) new_instance) + post_offset, ((char *) prototype) +
post_offset, post_history_len);
#endif
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2152) Create a tag that logs the destination IP of the client connection
[ https://issues.apache.org/jira/browse/TS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2152: -- Fix Version/s: 5.0.0 Create a tag that logs the destination IP of the client connection -- Key: TS-2152 URL: https://issues.apache.org/jira/browse/TS-2152 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Leif Hedstrom Fix For: 5.0.0 This would log the IP of the proxy server, as the client connected to. This is useful for two reasons: 1) A box can be multi-homed 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2151) Do we really need HttpSM::_instantiate_func() now?
[
https://issues.apache.org/jira/browse/TS-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2151:
--
Fix Version/s: 5.0.0
Do we really need HttpSM::_instantiate_func() now?
--
Key: TS-2151
URL: https://issues.apache.org/jira/browse/TS-2151
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Fix For: 5.0.0
The HttpSM implements the instantiate_func() which means the Sparse Class
allocator ends up trying to optimize the memcpy(). We should benchmark
this, and see if is actually a performance improvement still. Simplifying
this code with just a mempcy() (i.e. use normal class allocator behavior)
would make it safer and less confusing.
{code}
void
HttpSM::_instantiate_func(HttpSM * prototype, HttpSM * new_instance)
{
int history_len = sizeof(prototype-history);
int total_len = sizeof(HttpSM);
int pre_history_len = (char *) ((prototype-history)) - (char *) prototype;
int post_history_len = total_len - history_len - pre_history_len;
int post_offset = pre_history_len + history_len;
#ifndef SIMPLE_MEMCPY_INIT
int j;
memset(((char *) new_instance), 0, pre_history_len);
memset(((char *) new_instance) + post_offset, 0, post_history_len);
uint32_t *pd = (uint32_t *) new_instance;
for (j = 0; j scat_count; j++) {
pd[to[j]] = val[j];
}
ink_assert((memcmp((char *) new_instance, (char *) prototype,
pre_history_len) == 0)
(memcmp(((char *) new_instance) + post_offset, ((char *)
prototype) + post_offset, post_history_len) == 0));
#else
// memcpy(new_instance, prototype, total_len);
memcpy(new_instance, prototype, pre_history_len);
memcpy(((char *) new_instance) + post_offset, ((char *) prototype) +
post_offset, post_history_len);
#endif
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2153) traffic_manager -tsArgs doesn't work
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2153:
--
Fix Version/s: 4.2.0
traffic_manager -tsArgs doesn't work
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: Adam Twardowski
Fix For: 4.2.0
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2178) Transparent proxy should check for connection: close when use_client_source_port is enabled.
[ https://issues.apache.org/jira/browse/TS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2178: Summary: Transparent proxy should check for connection: close when use_client_source_port is enabled. (was: Transparent proxy should check for connection: close when use_cleitn_source_port is enabled.) Transparent proxy should check for connection: close when use_client_source_port is enabled. Key: TS-2178 URL: https://issues.apache.org/jira/browse/TS-2178 Project: Traffic Server Issue Type: Bug Components: TProxy Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor There are issues with keep alive and use client target address port. if the server closes such a connection, the client connection should also be closed. If, in such a case, the server sends Connection: close then ATS should disable keep alive on the client side and close the connection after the response has been sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2138) when restart ats, all data will be lost, miss return
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758060#comment-13758060
]
Leif Hedstrom commented on TS-2138:
---
I have not been able to reproduce this… Can you try 4.0.1 and verify the
behavior? You are sure it's opening and writing the disk caches properly?
when restart ats, all data will be lost, miss return
-
Key: TS-2138
URL: https://issues.apache.org/jira/browse/TS-2138
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: bettydramit
Attachments: 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2159) First log rotation should happen at proxy.config.log.rolling_size_mb
[ https://issues.apache.org/jira/browse/TS-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2159: - Assignee: Leif Hedstrom First log rotation should happen at proxy.config.log.rolling_size_mb Key: TS-2159 URL: https://issues.apache.org/jira/browse/TS-2159 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Adam Twardowski Assignee: Leif Hedstrom Priority: Minor Fix For: 4.2.0 If a 50MB log file exists, and proxy.config.log.rolling_size_mb is set to 100MB, then the first log rotate won't happen until it reaches 150MB. The logging system appears to be counting bytes written to the log instead of file size. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2178) Transparent proxy should check for connection: close when use_client_source_port is enabled.
[ https://issues.apache.org/jira/browse/TS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758070#comment-13758070 ] Leif Hedstrom commented on TS-2178: --- amc: if you are working on this for v4.1.0, change fix versions. Transparent proxy should check for connection: close when use_client_source_port is enabled. Key: TS-2178 URL: https://issues.apache.org/jira/browse/TS-2178 Project: Traffic Server Issue Type: Bug Components: TProxy Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 4.2.0 There are issues with keep alive and use client target address port. if the server closes such a connection, the client connection should also be closed. If, in such a case, the server sends Connection: close then ATS should disable keep alive on the client side and close the connection after the response has been sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2178) Transparent proxy should check for connection: close when use_client_source_port is enabled.
[ https://issues.apache.org/jira/browse/TS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2178: -- Fix Version/s: 4.2.0 Transparent proxy should check for connection: close when use_client_source_port is enabled. Key: TS-2178 URL: https://issues.apache.org/jira/browse/TS-2178 Project: Traffic Server Issue Type: Bug Components: TProxy Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 4.2.0 There are issues with keep alive and use client target address port. if the server closes such a connection, the client connection should also be closed. If, in such a case, the server sends Connection: close then ATS should disable keep alive on the client side and close the connection after the response has been sent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2109) Cache-Control: no-cache responses are not stored the cache
[ https://issues.apache.org/jira/browse/TS-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2109: -- Fix Version/s: 5.0.0 Cache-Control: no-cache responses are not stored the cache -- Key: TS-2109 URL: https://issues.apache.org/jira/browse/TS-2109 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Igor Brezac Fix For: 5.0.0 This can be duplicated using 3.3.5-dev (trunk). Cache-Control: must-revalidate suffers from the same issue. Cache-Control: max-age=0,must-revalidate works correctly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2159) First log rotation should happen at proxy.config.log.rolling_size_mb
[ https://issues.apache.org/jira/browse/TS-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2159: -- Fix Version/s: 4.2.0 First log rotation should happen at proxy.config.log.rolling_size_mb Key: TS-2159 URL: https://issues.apache.org/jira/browse/TS-2159 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Adam Twardowski Priority: Minor Fix For: 4.2.0 If a 50MB log file exists, and proxy.config.log.rolling_size_mb is set to 100MB, then the first log rotate won't happen until it reaches 150MB. The logging system appears to be counting bytes written to the log instead of file size. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2139) Twice purge to refresh object form cache when enable-interim-cache
[ https://issues.apache.org/jira/browse/TS-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2139: -- Assignee: Bin Chen Assigning to Bin Chen for now, please act on it as appropriate. Twice purge to refresh object form cache when enable-interim-cache -- Key: TS-2139 URL: https://issues.apache.org/jira/browse/TS-2139 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: bettydramit Assignee: Bin Chen Fix For: 5.0.0 Centos x86_64 gitmaster and http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2 when enable enable-interim-cache It muse use twice purge to refresh object form cache my records.config LOCAL proxy.config.cache.interim.storage STRING /dev/vdb Test example: [root@localhost trafficserver]# wget -SO /dev/null -e http_proxy=127.0.0.1 http://www.test.com/ben.bf --2013-08-17 14:45:23-- http://www.test.com/ben.bf Connecting to 127.0.0.1:80... connected. Proxy request sent, awaiting response... HTTP/1.0 200 OK Date: Sat, 17 Aug 2013 06:38:13 GMT Server: ATS/3.3.5-dev Last-Modified: Mon, 08 Jul 2013 15:26:09 GMT ETag: 41d26-103-4e101a9fc2c93 Accept-Ranges: bytes Content-Length: 259 Content-Type: text/plain; charset=UTF-8 Age: 430 Length: 259 [text/plain] Saving to: “/dev/null” 100%[] 259 --.-K/s in 0s 2013-08-17 14:45:23 (38.5 MB/s) - “/dev/null” saved [259/259] [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v http://www.test.com/ben.bf * About to connect() to proxy 127.0.0.1 port 80 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) purge http://www.test.com/ben.bf HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Host: www.test.com Accept: */* Proxy-Connection: Keep-Alive HTTP/1.1 200 OK Date: Sat, 17 Aug 2013 06:45:28 GMT Proxy-Connection: keep-alive Server: ATS/3.3.5-dev Content-Length: 0 * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v http://www.test.com/ben.bf * About to connect() to proxy 127.0.0.1 port 80 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) purge http://www.test.com/ben.bf HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Host: www.test.com Accept: */* Proxy-Connection: Keep-Alive HTTP/1.1 200 OK Date: Sat, 17 Aug 2013 06:45:29 GMT Proxy-Connection: keep-alive Server: ATS/3.3.5-dev Content-Length: 0 * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v http://www.test.com/ben.bf * About to connect() to proxy 127.0.0.1 port 80 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) purge http://www.test.com/ben.bf HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Host: www.test.com Accept: */* Proxy-Connection: Keep-Alive HTTP/1.1 404 Not Found Date: Sat, 17 Aug 2013 06:45:33 GMT Proxy-Connection: keep-alive Server: ATS/3.3.5-dev Content-Length: 0 * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2139) Twice purge to refresh object form cache when enable-interim-cache
[ https://issues.apache.org/jira/browse/TS-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2139: -- Fix Version/s: 5.0.0 Twice purge to refresh object form cache when enable-interim-cache -- Key: TS-2139 URL: https://issues.apache.org/jira/browse/TS-2139 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: bettydramit Fix For: 5.0.0 Centos x86_64 gitmaster and http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2 when enable enable-interim-cache It muse use twice purge to refresh object form cache my records.config LOCAL proxy.config.cache.interim.storage STRING /dev/vdb Test example: [root@localhost trafficserver]# wget -SO /dev/null -e http_proxy=127.0.0.1 http://www.test.com/ben.bf --2013-08-17 14:45:23-- http://www.test.com/ben.bf Connecting to 127.0.0.1:80... connected. Proxy request sent, awaiting response... HTTP/1.0 200 OK Date: Sat, 17 Aug 2013 06:38:13 GMT Server: ATS/3.3.5-dev Last-Modified: Mon, 08 Jul 2013 15:26:09 GMT ETag: 41d26-103-4e101a9fc2c93 Accept-Ranges: bytes Content-Length: 259 Content-Type: text/plain; charset=UTF-8 Age: 430 Length: 259 [text/plain] Saving to: “/dev/null” 100%[] 259 --.-K/s in 0s 2013-08-17 14:45:23 (38.5 MB/s) - “/dev/null” saved [259/259] [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v http://www.test.com/ben.bf * About to connect() to proxy 127.0.0.1 port 80 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) purge http://www.test.com/ben.bf HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Host: www.test.com Accept: */* Proxy-Connection: Keep-Alive HTTP/1.1 200 OK Date: Sat, 17 Aug 2013 06:45:28 GMT Proxy-Connection: keep-alive Server: ATS/3.3.5-dev Content-Length: 0 * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v http://www.test.com/ben.bf * About to connect() to proxy 127.0.0.1 port 80 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) purge http://www.test.com/ben.bf HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Host: www.test.com Accept: */* Proxy-Connection: Keep-Alive HTTP/1.1 200 OK Date: Sat, 17 Aug 2013 06:45:29 GMT Proxy-Connection: keep-alive Server: ATS/3.3.5-dev Content-Length: 0 * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v http://www.test.com/ben.bf * About to connect() to proxy 127.0.0.1 port 80 (#0) * Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) purge http://www.test.com/ben.bf HTTP/1.1 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Host: www.test.com Accept: */* Proxy-Connection: Keep-Alive HTTP/1.1 404 Not Found Date: Sat, 17 Aug 2013 06:45:33 GMT Proxy-Connection: keep-alive Server: ATS/3.3.5-dev Content-Length: 0 * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2134) SRV lookup does not handle failover correctly
[ https://issues.apache.org/jira/browse/TS-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2134: -- Fix Version/s: 5.0.0 SRV lookup does not handle failover correctly - Key: TS-2134 URL: https://issues.apache.org/jira/browse/TS-2134 Project: Traffic Server Issue Type: Bug Components: DNS, HTTP Reporter: Thach Tran Fix For: 5.0.0 Attachments: ats.log I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail over to alternative origins once the first choice is marked as down. To reproduce this, I'm running dnsmasq as a local resolver to serve up the test SRV records. My configuration is as follows. h4. records.config CONFIG proxy.config.dns.nameservers STRING 127.0.0.1 CONFIG proxy.config.dns.resolv_conf STRING NULL CONFIG proxy.config.srv_enabled INT 1 h4. remap.config regex_remap http://.*:8080/ https://noexample.com/ h4. dnsmasq.conf (srv records config) srv-host=_http._tcp.noexample.com,abc.com,443,0,100 srv-host=_http._tcp.noexample.com,google.com,443,1,100 The intention is since the srv lookup for _http._tcp.noexample.com returns abc.com:443 and google.com:443 with abc.com:443 being the one with higher priority, the proxy should try that first and once the connection to abc.com:443 is marked as down (up to 6 retries by default), google.com:443 should be tried next and the connection should succeed then. However, testing with the following curl command multiple times still gives back 502. $ curl -v http://localhost:8080/ Debug log seems to suggest it always attempts abc.com:443. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2134) SRV lookup does not handle failover correctly
[ https://issues.apache.org/jira/browse/TS-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758072#comment-13758072 ] Leif Hedstrom commented on TS-2134: --- Does anyone at Alibaba/Taobao want to take this? SRV lookup does not handle failover correctly - Key: TS-2134 URL: https://issues.apache.org/jira/browse/TS-2134 Project: Traffic Server Issue Type: Bug Components: DNS, HTTP Reporter: Thach Tran Attachments: ats.log I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail over to alternative origins once the first choice is marked as down. To reproduce this, I'm running dnsmasq as a local resolver to serve up the test SRV records. My configuration is as follows. h4. records.config CONFIG proxy.config.dns.nameservers STRING 127.0.0.1 CONFIG proxy.config.dns.resolv_conf STRING NULL CONFIG proxy.config.srv_enabled INT 1 h4. remap.config regex_remap http://.*:8080/ https://noexample.com/ h4. dnsmasq.conf (srv records config) srv-host=_http._tcp.noexample.com,abc.com,443,0,100 srv-host=_http._tcp.noexample.com,google.com,443,1,100 The intention is since the srv lookup for _http._tcp.noexample.com returns abc.com:443 and google.com:443 with abc.com:443 being the one with higher priority, the proxy should try that first and once the connection to abc.com:443 is marked as down (up to 6 retries by default), google.com:443 should be tried next and the connection should succeed then. However, testing with the following curl command multiple times still gives back 502. $ curl -v http://localhost:8080/ Debug log seems to suggest it always attempts abc.com:443. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1799) Segmentation fault (git master) at cluster
[
https://issues.apache.org/jira/browse/TS-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758077#comment-13758077
]
Leif Hedstrom commented on TS-1799:
---
Bettydramit: Can you verify that this is still an issue in v4.0.1 ?
Segmentation fault (git master) at cluster
---
Key: TS-1799
URL: https://issues.apache.org/jira/browse/TS-1799
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.3.2
Reporter: bettydramit
Labels: crash
{code}
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b20d9026500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2b20d901e851]
/lib64/libc.so.6(clone+0x6d)[0x2b20db6b090d]
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b8d852ea500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
/usr/bin/traffic_server(ClusterHandler::cluster_signal_and_update(int,
ClusterVConnection*, ClusterVConnState*)+0x33)[0x605b43]
/usr/bin/traffic_server(ClusterHandler::valid_for_data_write(ClusterVConnection*)+0x61e)[0x60316e]
/usr/bin/traffic_server(ClusterHandler::build_write_descriptors()+0xbd)[0x6034cd]
/usr/bin/traffic_server[0x604490]
/usr/bin/traffic_server(ClusterHandler::mainClusterEvent(int,
Event*)+0x1e4)[0x604774]
/usr/bin/traffic_server(ClusterState::IOComplete()+0xc2)[0x60b472]
/usr/bin/traffic_server(ClusterState::doIO_write_event(int,
void*)+0x109)[0x60b7e9]
/usr/bin/traffic_server[0x66f321]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x847)[0x671b57]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x286)[0x66a086]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2b8d852e2851]
/lib64/libc.so.6(clone+0x6d)[0x2b8d8797490d]
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b12fb535500]
/usr/bin/traffic_server(UnixNetVConnection::do_io_write(Continuation*, long,
IOBufferReader*, bool)+0x18)[0x6708b8]
/usr/bin/traffic_server(HttpSessionManager::release_session(HttpServerSession*)+0x7d)[0x515b2d]
/usr/bin/traffic_server(HttpSM::tunnel_handler_server(int,
HttpTunnelProducer*)+0x2ff)[0x523faf]
/usr/bin/traffic_server(HttpTunnel::producer_handler(int,
HttpTunnelProducer*)+0x196)[0x565ba6]
/usr/bin/traffic_server(HttpTunnel::consumer_handler(int,
HttpTunnelConsumer*)+0x666)[0x5666c6]
/usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x11d)[0x56694d]
[jira] [Resolved] (TS-72) Records config review for update type behavior
[ https://issues.apache.org/jira/browse/TS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-72. - Resolution: Won't Fix Closing. Lets open more specific bugs as we find / fix things. Records config review for update type behavior -- Key: TS-72 URL: https://issues.apache.org/jira/browse/TS-72 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 2.0.0a Environment: All Reporter: George Paul Priority: Minor The Records configuration variables need to be reviewed for proper intended update type behavior. The update types can be the following: RU_NULL, // default: don't know the behavior RU_REREAD,// config can be updated dynamically w/ traffic_line -x RU_RESTART_TS,// config requires TS to be restarted to take effect RU_RESTART_TM, // config requires TM/TS to be restarted to take effect RU_RESTART_TC // config requires TC/TM/TS to be restarted to take effect This will require review of the overall system and component configs. Possibly split this ticket into seperate tickets targeted to the various components. -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-32) Fix ICP
[ https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-32: Fix Version/s: (was: 5.0.0) sometime Fix ICP --- Key: TS-32 URL: https://issues.apache.org/jira/browse/TS-32 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Reporter: Miles Libbey Fix For: sometime http://icp.ircache.net/ The ICP implementation in Traffic Server broke when epoll() was introduced. Its still an interesting and used feature in caches: - when a caching layer of several boxes are used ICP helps to reduce disparities when a client is not routed to the same cache on subsequent requests - after a restart, it can help reduce the time spent in a cold cache situation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-214) On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe)
[ https://issues.apache.org/jira/browse/TS-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758087#comment-13758087 ] Leif Hedstrom commented on TS-214: -- Theo: Is this something we still care about? Should we close it as won't fix? On Solaris, use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe) - Key: TS-214 URL: https://issues.apache.org/jira/browse/TS-214 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.0.0 Environment: OpenSolaris Reporter: John Plevyak Assignee: Theo Schlossnagle Fix For: 5.0.0 We should use port_send to signal async events to a waiting thread (e.g. like eventfd/pipe). http://developers.sun.com/solaris/articles/event_completion.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-232) Startup script should use lsb when available
[ https://issues.apache.org/jira/browse/TS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-232. -- Resolution: Won't Fix Fix Version/s: (was: sometime) Startup script should use lsb when available -- Key: TS-232 URL: https://issues.apache.org/jira/browse/TS-232 Project: Traffic Server Issue Type: Improvement Components: Portability Reporter: Leif Hedstrom Priority: Minor I don't know how much of a change this would be, but I think we should change the startup script so that for all distros that have lsb support, we should use that for the start/stop/status etc. functionality. This would take precedence over special distros functionality, and could hopefully clean out some code too. We need to leave the existing pieces where there are distros that do not have modern lsb capabilities. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-274) UA side SSL support in forward proxy
[
https://issues.apache.org/jira/browse/TS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-274:
-
Fix Version/s: (was: 4.2.0)
sometime
UA side SSL support in forward proxy
Key: TS-274
URL: https://issues.apache.org/jira/browse/TS-274
Project: Traffic Server
Issue Type: New Feature
Components: SSL
Affects Versions: 2.1.0, 2.0.0a
Environment: Debian, Linux 2.6.18 32-bit
Reporter: Marcus Clyne
Labels: ssl
Fix For: sometime
Using self-signed SSL certificates, which are in the correct paths under
$prefix, and giving no startup errors, I get the following error when making
a request through the proxy :
Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
SSL_ServerHandShake.
Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR:
SSL::5:error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy
request:s23_srvr.c:384:
Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
SSL_ServerHandShake.
Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR:
SSL::5:error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http
request:s23_srvr.c:379:
The first of these two was from using Proxifier (Windows software) to connect
to the server, the second is from using `curl -k -x $ip:443
http://google.com/`.
The issue appears on the latest trunk version and the 2.0.x branch as of
today when used in forward proxy mode.
I have not personally tested in reverse proxy mode, but zwoop (Freenode IRC
name) tested in reverse proxy mode, and reverse proxy mode worked only in the
2.0.x but not trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2174:
-
Attachment: 0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch
traffic_shell/traffic_line miss some stats value
Key: TS-2174
URL: https://issues.apache.org/jira/browse/TS-2174
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.1.0
Attachments:
0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
I'm sorry for too late to fix this bug.
Here is an example about the broken of traffic_shell(reported by
Esmqe...@163.com ):
{code}
echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
Successfully Initialized MgmtAPI in
/usr/local/trafficserver-4.0.1/var/trafficserver
trafficserver
Document Hit Rate 0.00 %*
Ram cache Hit Rate --- 0.00 %*
Bandwidth Saving - 0.00 %*
Cache Percent Free --- 0.00 %
Open Server Connections -- 473
Open Client Connections -- 3796
Open Cache Connections --- 1
Client Throughput 18.100512 MBit/Sec
Transaction Per Second --- 0.00
{code}
The root cause is that StatBinaryEval() use RecInt type to hold the result of
*div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-235) cleanup libinktomi++
[ https://issues.apache.org/jira/browse/TS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-235. -- Resolution: Won't Fix Fix Version/s: (was: 5.0.0) Assignee: (was: John Plevyak) This has been fixed in a number of other commits / lira's, and we can do whatever is left as more detailed bugs. cleanup libinktomi++ Key: TS-235 URL: https://issues.apache.org/jira/browse/TS-235 Project: Traffic Server Issue Type: Improvement Components: Cleanup Affects Versions: 2.1.6 Reporter: John Plevyak Priority: Critical Attachments: rename-inkmd5.sh libinktomi++ is a bit of a mess... e.g. ink_port.h Portability.h Compatability.h, yes you guessed it, they all do very similar things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-303) plugin idea: - a config option to transform a 'no-cache' directive into a validation 'if-modified-since' request
[ https://issues.apache.org/jira/browse/TS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-303. -- Resolution: Won't Fix Fix Version/s: (was: sometime) This doesn't need a specific plugin, existing plugins can achieve this via configurations. plugin idea: - a config option to transform a 'no-cache' directive into a validation 'if-modified-since' request Key: TS-303 URL: https://issues.apache.org/jira/browse/TS-303 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Miles Libbey Priority: Minor (moved from yahoo bug 633221) Original description by John Allspaw 4 years ago at 2006-04-17 11:04 This does disobey some of the HTTP specification, but it is a great performance win when you're totally sure that something hasn't/can't be changed. Squid has this, and this is ideally how it goes: When set, this option would make TrafficServer transform a request with a no-cache directive into a validation (If-Modified-Since) request. In other words, TrafficServer ads an If-Modified-Since header to the request before forwarding it on. Note that this would only work for objects that have a Last-Modified timestamp. Comment 1 by Mark Nottingham 4 years ago at 2006-04-17 13:14:30 They other thing you could (optionally, depending on config?) do is to ignore cache-control request headers all together. If you're confident of the cache's correctness, this doesn't allow the browser to force a round trip back to your origin server (which could be an attack vector). It really doesn't break HTTP if you're acting as a gateway; they're allowed to do pretty much what they want. Comment 2 by John Allspaw 4 years ago at 2006-04-17 13:20:33 Mark: yeah, TS does already have the option to completely ignore cache-control headers, confirmed by Leif. I've generally thought that having the transform into IMS just adds a slight amount of flexibility than the baby/bathwater if totally ignoring. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758100#comment-13758100
]
Yunkai Zhang commented on TS-2174:
--
After applied two attached patches:
1)0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
2)0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch
{code}
% trafficserver show:proxy-stats
Document Hit Rate 99.893990 % *
Ram cache Hit Rate --- 99.890579 % *
Bandwidth Saving - 99.905785 % *
Cache Percent Free --- 99.993896 %
Open Server Connections -- 0
Open Client Connections -- 118
Open Cache Connections --- 3
Client Throughput 2424.848145 MBit/Sec
Transaction Per Second --- 16628.626953
* Value represents 10 second average.
{code}
Transaction Per Second value is ok now.
traffic_shell/traffic_line miss some stats value
Key: TS-2174
URL: https://issues.apache.org/jira/browse/TS-2174
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.1.0
Attachments:
0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
I'm sorry for too late to fix this bug.
Here is an example about the broken of traffic_shell(reported by
Esmqe...@163.com ):
{code}
echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
Successfully Initialized MgmtAPI in
/usr/local/trafficserver-4.0.1/var/trafficserver
trafficserver
Document Hit Rate 0.00 %*
Ram cache Hit Rate --- 0.00 %*
Bandwidth Saving - 0.00 %*
Cache Percent Free --- 0.00 %
Open Server Connections -- 473
Open Client Connections -- 3796
Open Cache Connections --- 1
Client Throughput 18.100512 MBit/Sec
Transaction Per Second --- 0.00
{code}
The root cause is that StatBinaryEval() use RecInt type to hold the result of
*div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-274) UA side SSL support in forward proxy
[
https://issues.apache.org/jira/browse/TS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-274:
--
Assignee: Alan M. Carroll
UA side SSL support in forward proxy
Key: TS-274
URL: https://issues.apache.org/jira/browse/TS-274
Project: Traffic Server
Issue Type: New Feature
Components: SSL
Affects Versions: 2.1.0, 2.0.0a
Environment: Debian, Linux 2.6.18 32-bit
Reporter: Marcus Clyne
Assignee: Alan M. Carroll
Labels: ssl
Fix For: sometime
Using self-signed SSL certificates, which are in the correct paths under
$prefix, and giving no startup errors, I get the following error when making
a request through the proxy :
Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
SSL_ServerHandShake.
Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR:
SSL::5:error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy
request:s23_srvr.c:384:
Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
SSL_ServerHandShake.
Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR:
SSL::5:error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http
request:s23_srvr.c:379:
The first of these two was from using Proxifier (Windows software) to connect
to the server, the second is from using `curl -k -x $ip:443
http://google.com/`.
The issue appears on the latest trunk version and the 2.0.x branch as of
today when used in forward proxy mode.
I have not personally tested in reverse proxy mode, but zwoop (Freenode IRC
name) tested in reverse proxy mode, and reverse proxy mode worked only in the
2.0.x but not trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758108#comment-13758108
]
ASF subversion and git services commented on TS-2174:
-
Commit b71ca5521466b22b44500bd09adb128081a573ea in branch refs/heads/master
from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b71ca55 ]
TS-2174: Assign proper type for uninitialized expression token
In librecords, not all token are register at initialization,
we must assign proper type if it is undefined.
Signed-off-by: Yunkai Zhang qiushu@taobao.com
traffic_shell/traffic_line miss some stats value
Key: TS-2174
URL: https://issues.apache.org/jira/browse/TS-2174
Project: Traffic Server
Issue Type: Bug
Components: Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.1.0
Attachments:
0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
I'm sorry for too late to fix this bug.
Here is an example about the broken of traffic_shell(reported by
Esmqe...@163.com ):
{code}
echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
Successfully Initialized MgmtAPI in
/usr/local/trafficserver-4.0.1/var/trafficserver
trafficserver
Document Hit Rate 0.00 %*
Ram cache Hit Rate --- 0.00 %*
Bandwidth Saving - 0.00 %*
Cache Percent Free --- 0.00 %
Open Server Connections -- 473
Open Client Connections -- 3796
Open Cache Connections --- 1
Client Throughput 18.100512 MBit/Sec
Transaction Per Second --- 0.00
{code}
The root cause is that StatBinaryEval() use RecInt type to hold the result of
*div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-305) sigTERM should cause a user-friendly shutdown
[ https://issues.apache.org/jira/browse/TS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-305. -- Resolution: Won't Fix Fix Version/s: (was: 5.0.0) sigTERM should cause a user-friendly shutdown - Key: TS-305 URL: https://issues.apache.org/jira/browse/TS-305 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Miles Libbey Priority: Minor (from yahoo bug 848837) Original description by Scott Manjourides 3 years ago at 2006-10-16 15:48 On Monday 16 October 2006 03:01 pm, Ryan Troll wrote: Open a RFE asking to have sigTERM cause a user-friendly shutdown? Something like: - immediately set all KeepAlive timeout values to 5 seconds :: Optional, but could make shutdown faster than leaving at :: whatever the property specified. - no longer accept new connections - process exits when all existing connections close -R -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-309) xdebug: Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-309. -- Resolution: Duplicate Fix Version/s: (was: 5.0.0) xdebug: Report OS Errors in Header -- Key: TS-309 URL: https://issues.apache.org/jira/browse/TS-309 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Miles Libbey Labels: A (from yahoo bug 1021194) Original description by Ryan Troll 3 years ago at 2007-01-17 13:20 Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 Scott asked for a way to look at a YTS response and differentiate between a TS error, and an Origin server error. I *think* the general idea is that, whenever the origin server returns an error; we return it to the client. However, if there's a problem contacting the origin server, we should return the appropriate HTTP response: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 including 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported and specify what Origin Server triggered the error in the Warning header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 I think we could define our own warn code and use it specify the origin server host (by name and IP): 504 Gateway Timeout Date: Wed, 17 Jan 2007 21:17:25 GMT Warning: 599 l1.ycs.s1s.yahoo.com:80 OS: us.yimg.com [66.218.71.81] But that's just a thought. Maybe mnot has a good suggestion -- he pointed us towards the Warning: header, and may know of good examples of it's use in the real world. Comment 1 by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 There's a pretty cool feature in TS, where it embeds codes into a Via header (if those are turned on) where someone looking at the headers can see whether it was a cache hit, an IMS hit, etc. As it moves through the state machine, it appends characters to the string - and in the reply you get something like [uN l oS f pS eN] which would translate to a user issuing a no-cache pragma, that resulted in an origin server fetch, which was served without error. It's pretty useful, so we might want to consider enabling this. There's a cheat sheet at /dev/traffic/trunk/proxy/http2/README.via chuck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-318) TS doesn't guard itself well against the system time going backwards
[ https://issues.apache.org/jira/browse/TS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-318. -- Resolution: Cannot Reproduce Fix Version/s: (was: sometime) This does not seem to reproduce any more, so closing. TS doesn't guard itself well against the system time going backwards - Key: TS-318 URL: https://issues.apache.org/jira/browse/TS-318 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Miles Libbey (was yahoo bug 2156845) Original description by Bryan Call 19 months ago at 2008-08-20 08:57 TS doesn't guard itself well against the system time going backwards (for instance in daylight savings time). Age header gets messed up and it looks like connections will timeout: Hi I ran into the following interesting behavior by accident: If the system clock changes while TS is running, TS will generate Age: header. This breaks a number of things, monitoring check being one of them. Example: From mon.corp.sp1: $ /home/libexec/check_http -w 50 -c 100 --http-version 1.0 -H coolie-status-url.yimg.com -u /magicnumbers -I .a2s.yahoo.net -vvv GET /magicnumbers HTTP/1.0 User-Agent: check_http/v1.5 (nagios-plugins 1.4.10) Connection: close Host: coolie-status-url.yimg.com http://s1.ycpi.a2s.yahoo.net:80/magicnumbers is 181 characters STATUS: HTTP/1.0 200 (OK) HEADER Cache-Control: private Date: Wed, 20 Aug 2008 06:10:03 GMT Server: YTS/1.17.8 Content-Length: 25 Content-Type: text/plain Age: 0 CONTENT 1219212603 0 80 93 On s1.ycpi.a2s.yahoo.net, changing the clock 1 hour back: $ date Tue Aug 19 23:10:32 PDT 2008 $ sudo date 08192210 Tue Aug 19 22:10:00 PDT 2008 Again, testing from the mnode - check_http times out, curl reports the Age header: $ home/libexec/check_http -w 5 -c 10 --http-version 1.0 -H coolie-status-url.yimg.com -u /magicnumbers -I s1.ycpi.a2s.yahoo.net -vvv GET /magicnumbers HTTP/1.0 User-Agent: check_http/v1.5 (nagios-plugins 1.4.10) Connection: close Host: coolie-status-url.yimg.com CRITICAL - Socket timeout after 10 seconds $ curl -D - -H 'Host: coolie-status-url.yimg.com' http://s1.ycpi.a2s.yahoo.net/magicnumbersHTTP/1.1 200 (OK) Cache-Control: private Date: Wed, 20 Aug 2008 05:11:28 GMT Server: YTS/1.17.8 Content-Type: text/plain Age: 3597 Transfer-Encoding: chunked Connection: keep-alive 1219209088 1 80 93 Restarting TS fixes it: $ restart ytrafficserver trafficserver-1.17.9: restarting ... $ home/libexec/check_http -w 5 -c 10 --http-version 1.0 -H coolie-status-url.yimg.com -u /magicnumbers -I s1.ycpi.a2s.yahoo.net -vvv GET /magicnumbers HTTP/1.0 User-Agent: check_http/v1.5 (nagios-plugins 1.4.10) Connection: close Host: coolie-status-url.yimg.com http://s1.ycpi.a2s.yahoo.net:80/magicnumbers is 181 characters STATUS: HTTP/1.0 200 (OK) HEADER Cache-Control: private Date: Wed, 20 Aug 2008 05:16:01 GMT Server: YTS/1.17.9 Content-Length: 25 Content-Type: text/plain Age: 0 CONTENT 1219209361 3 80 93 HTTP OK HTTP/1.0 200 (OK) - 181 bytes in 0.268 seconds |time=0.267525 size=181 Rolling the clock FORWARD does not cause any impact. -- Ivan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-341) Update Contrib Scripts
[ https://issues.apache.org/jira/browse/TS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758120#comment-13758120 ] Leif Hedstrom commented on TS-341: -- jason: Is this still an issue? If not, lets close this and possible file more detailed bugs. Update Contrib Scripts -- Key: TS-341 URL: https://issues.apache.org/jira/browse/TS-341 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 2.0.0 Environment: EC2 Reporter: Jason Giedymin Priority: Minor Labels: Contrib, EC2, Scripts Fix For: sometime - The EC2 images i created last month had updates to the contrib scripts which need to be synced with the source repo. - Need to udpate the scripts to point to the source repo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-346: - Fix Version/s: (was: 5.0.0) 4.2.0 ATS does not verify server certificate -- Key: TS-346 URL: https://issues.apache.org/jira/browse/TS-346 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: vijaya bhaskar mamidi Priority: Critical Labels: A Fix For: 4.2.0 ATS does not verify the certificates correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-340) EC2 Updates/Testing/Building
[ https://issues.apache.org/jira/browse/TS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758118#comment-13758118 ] Leif Hedstrom commented on TS-340: -- Jason: Anything left to do here? Can we close this? Should we file separate bugs on more detailed tasks? EC2 Updates/Testing/Building Key: TS-340 URL: https://issues.apache.org/jira/browse/TS-340 Project: Traffic Server Issue Type: Bug Components: Build, Portability Affects Versions: 3.0.0, 2.0.0a Environment: EC2 Reporter: Jason Giedymin Priority: Minor Labels: AMI, EC2, Fedora, Ubuntu Fix For: sometime 1.) More Lucid Testing 2.) Rebuild with latest ATS Release 3.) Seed to West, EU, Asia datacenters (20 Images in total, Fedora/Ubuntu9/Ubuntu10/32/64) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758143#comment-13758143 ] Leif Hedstrom commented on TS-541: -- ming_zym: is this still an issue? Do we commit it? Close it? SplitDNS cleanup in project HostDBandDNS Key: TS-541 URL: https://issues.apache.org/jira/browse/TS-541 Project: Traffic Server Issue Type: Improvement Components: Cleanup, DNS Reporter: Zhao Yongming Priority: Minor Fix For: 4.2.0 Attachments: TS-541.patch as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns processor. this may be another fix for TS-435. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-548) What is Initialize.cc /.h ??
[ https://issues.apache.org/jira/browse/TS-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758150#comment-13758150 ] Leif Hedstrom commented on TS-548: -- Do we really need standalone IOCORE anyways ? What is Initialize.cc /.h ?? Key: TS-548 URL: https://issues.apache.org/jira/browse/TS-548 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: Leif Hedstrom Fix For: sometime This code isn't built, nor used, as far as I can tell, and seems duplicated from what is available and used elsewhere. What is it? Should it be removed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-764) Traffic Server does not ship any documentation
[ https://issues.apache.org/jira/browse/TS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-764. -- Resolution: Fixed Fix Version/s: (was: Doc 3.4) I'm going to mark this as fixed. We are now including all Sphinx docs in the source ball, some man pages etc. I think it's better to file or add docs to more specific bugs as appropriate. Feel free to reopen if you disagree. Traffic Server does not ship any documentation --- Key: TS-764 URL: https://issues.apache.org/jira/browse/TS-764 Project: Traffic Server Issue Type: Improvement Components: Documentation Affects Versions: 2.1.8 Reporter: Arno Toell A major problem for ATS to the unskilled user as of today is, there is no on-line documentation besides the (somewhat scarce) information from the home page is available. In particular ATS misses * first of all: man pages * Description of command line switches (if any), including an interactive help, e.g. the common _-h/--help_ switch. * Description of the used environment, e.g. _$TS_ROOT_ where applicable. I think this would be an important release goal for the 3.0 release since that branch is intended for productive use, not by developers. If someone provides me the information or has all needed information in a written form, I could assist to provide man pages. I'm aware there is some documentation for _traffic_shell_ commands. I'm unsure if the documentation there reflects the most recent development and is generally up to date. If it is still suitable for ATS as of today, it should be merged with any newly created documentation. As a remark: I remember there was some discussion in the past, where to install the man pages because of the rather generic names, for example enable, disable, exit, ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-891) Crash report: mime_hdr_sanity_check in mime_parser_parse during
[
https://issues.apache.org/jira/browse/TS-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758191#comment-13758191
]
Leif Hedstrom commented on TS-891:
--
ming_zym: Still an issue?
Crash report: mime_hdr_sanity_check in mime_parser_parse during
Key: TS-891
URL: https://issues.apache.org/jira/browse/TS-891
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.1
Environment: v3.0.1, submit from user
Reporter: Zhao Yongming
Labels: crash
Fix For: 5.0.0
no other information, place holding first.
{code}
zym@zym6400 ~ $ c++filt /tmp/a
FATAL: MIME.cc:576: failed assert `strncasecmp(field-m_ptr_name, wks,
field-m_len_name) == 0`
/usr/local/ts/bin/traffic_server - STACK TRACE:
/usr/local/ts/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0x4003109b]
/usr/local/ts/lib/libtsutil.so.3(ink_fatal+0x2b)[0x400310ed]
/usr/local/ts/lib/libtsutil.so.3(_ink_assert+0xc4)[0x4002fd54]
/usr/local/ts/bin/traffic_server(mime_hdr_sanity_check(MIMEHdrImpl*)+0x323)[0x823f5c8]
/usr/local/ts/bin/traffic_server(mime_hdr_field_attach(MIMEHdrImpl*,
MIMEField*, int, MIMEField*)+0x36[0x8241e17]
/usr/local/ts/bin/traffic_server(mime_parser_parse(MIMEParser*, HdrHeap*,
MIMEHdrImpl*, char const**, char const*, bool, bool)+0x2b5)[0x82442b6]
/usr/local/ts/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x801)[0x823ae17]
/usr/local/ts/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x126)[0x82380f4]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x2f0)[0x819b87c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1f[0x81a0cc0]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x47)[0x81154f9]
/usr/local/ts/bin/traffic_server[0x82f644c]
/usr/local/ts/bin/traffic_server[0x82f6e43]
/usr/local/ts/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*,
EThread*)+0x17)[0x82f8c6d]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x62a)[0x82f2ea4]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x47)[0x81154f9]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x114)[0x831af5a]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x425)[0x831b529]
/usr/local/ts/bin/traffic_server(main+0x1245)[0x813f233]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x40476450]
/usr/local/ts/bin/traffic_server[0x80f60e1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-879) Seek on cached file
[ https://issues.apache.org/jira/browse/TS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-879: - Fix Version/s: (was: 5.0.0) sometime Seek on cached file --- Key: TS-879 URL: https://issues.apache.org/jira/browse/TS-879 Project: Traffic Server Issue Type: Bug Components: Cache, TS API Affects Versions: 3.0.0 Reporter: Nelson Pérez Labels: api-addition, cache, trafficserver Fix For: sometime I want a custom written plugin to be able to seek to any point in a cached file. According to John Plevyak (http://www.mail-archive.com/dev@trafficserver.apache.org/msg02785.html) this feature is new in the cache, but not yet available to the API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1174) Should we eliminate all ERR_* status message in squid logging?
[
https://issues.apache.org/jira/browse/TS-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1174:
--
Fix Version/s: (was: 5.0.0)
4.2.0
Should we eliminate all ERR_* status message in squid logging?
Key: TS-1174
URL: https://issues.apache.org/jira/browse/TS-1174
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Leif Hedstrom
Fix For: 4.2.0
In more recent versions of Squid, ERR_* status messages have been merged into
the status code. E.g.
{code}
ERR_*
Errors are now contained in the status code.
{code}
Should we do likewise?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758195#comment-13758195
]
Leif Hedstrom commented on TS-947:
--
Can this be closed ? It sounds like it can ?
AIO Race condition on non NT systems
Key: TS-947
URL: https://issues.apache.org/jira/browse/TS-947
Project: Traffic Server
Issue Type: Bug
Components: Core
Environment: stock build with static libts, running on a 4 core server
Reporter: B Wyatt
Assignee: John Plevyak
Fix For: 4.2.0
Attachments: lock-safe-AIO.patch, timed-wait-AIO.patch
Refer to code below. The timeslice starting when a consumer thread
determines that the temp_list is empty (A) and ending when it releases the
aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
and as a result request producers enqueue items on the temporary atomic list
(D). As a consumer in this state will wait for a signal on aio_cond to
proceed before processing the temp_list again, any requests on the temp_list
are effectively stalled until a future request produces this signal or
manually processes the temp_list.
In the case of cache volume initialization, there is no future request and
the initialization sequence soft locks.
{code:title=iocore/aio/AIO.cc(annotated)}
void *
aio_thread_main(void *arg)
{
...
ink_mutex_acquire(my_aio_req-aio_mutex);
for (;;) {
do {
current_req = my_aio_req;
/* check if any pending requests on the atomic list */
A if (!INK_ATOMICLIST_EMPTY(my_aio_req-aio_temp_list))
aio_move(my_aio_req);
if (!(op = my_aio_req-aio_todo.pop()) !(op =
my_aio_req-http_aio_todo.pop()))
Bbreak;
...
service request
...
} while (1);
Cink_cond_wait(my_aio_req-aio_cond, my_aio_req-aio_mutex);
}
...
}
static void
aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
{
...
if (!ink_mutex_try_acquire(req-aio_mutex)) {
Dink_atomiclist_push(req-aio_temp_list, op);
} else {
/* check if any pending requests on the atomic list */
if (!INK_ATOMICLIST_EMPTY(req-aio_temp_list))
aio_move(req);
/* now put the new request */
aio_insert(op, req);
ink_cond_signal(req-aio_cond);
ink_mutex_release(req-aio_mutex);
}
...
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1132) Clean up usage of HDR_BUF_RONLY_HEAPS
[ https://issues.apache.org/jira/browse/TS-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1132. --- Resolution: Fixed Fix Version/s: (was: sometime) Clean up usage of HDR_BUF_RONLY_HEAPS - Key: TS-1132 URL: https://issues.apache.org/jira/browse/TS-1132 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom We should clean up the usage of HDR_BUF_RONLY_HEAPS, and not assume it's always 3. In addition, we should consider making this configurable, via either records.config, or at least configure.ac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1139) Expose API such that plugins can easily be written in a glue-language such as Lua.
[ https://issues.apache.org/jira/browse/TS-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758207#comment-13758207 ] Leif Hedstrom commented on TS-1139: --- Igor: isn't this done with the Lua plugin? If so, can we close please? Expose API such that plugins can easily be written in a glue-language such as Lua. -- Key: TS-1139 URL: https://issues.apache.org/jira/browse/TS-1139 Project: Traffic Server Issue Type: New Feature Components: Lua Reporter: Igor Galić Fix For: sometime Let's be honest here: our plugin API is great. But woulnd't it be great if we didn't just expose it to C/C++ but also to a script language, like Lua? I think it would be cool if an admin (I think they are be our main target group here) could hack up a couple of lines of Lua script and already have a great (prototype of a) plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-972) traffic_line should warn if a command didn't succeed
[
https://issues.apache.org/jira/browse/TS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-972:
-
Fix Version/s: (was: 5.0.0)
sometime
traffic_line should warn if a command didn't succeed
Key: TS-972
URL: https://issues.apache.org/jira/browse/TS-972
Project: Traffic Server
Issue Type: Improvement
Components: Management API
Affects Versions: 3.1.0, 3.0.1
Reporter: Arno Toell
Fix For: sometime
{{traffic_line}} is a handy tool to manage a traffic server instance. For
example it is possible to retrieve and set configuration settings through
command line like this:
{code}
root@wv-tmp2:/home/at# traffic_line -r proxy.config.http.server_port ; echo $?
81
0
{code}
However, some commans can be set, but aren't effective until the server is
restarted, despite of ATS offering the _-x_ option to flush configuration and
reread new settings:
{code}
root@wv-tmp2:/home/at# traffic_line -s proxy.config.http.server_port -v 80 ;
echo $?
0
root@wv-tmp2:/home/at# traffic_line -x ; echo $?
0
{code}
Trafficserver should possibly warn when setting such settings which aren't
effective until the server is restarted and leave with a non-zero exit status
for _-x_ in such cases.
Moreover {{traffic_line}} does not work at all if the manager is not running:
{code}
# traffic_line -r proxy.config.http.server_port ; echo $?
traffic_line: Variable Not Found
1
{code}
That's all right, but the error message shall be improved telling that. :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1174) Should we eliminate all ERR_* status message in squid logging?
[
https://issues.apache.org/jira/browse/TS-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1174:
-
Assignee: Leif Hedstrom
Should we eliminate all ERR_* status message in squid logging?
Key: TS-1174
URL: https://issues.apache.org/jira/browse/TS-1174
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 4.2.0
In more recent versions of Squid, ERR_* status messages have been merged into
the status code. E.g.
{code}
ERR_*
Errors are now contained in the status code.
{code}
Should we do likewise?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-972) traffic_line should warn if a command didn't succeed
[
https://issues.apache.org/jira/browse/TS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-972.
--
Resolution: Fixed
Fix Version/s: (was: sometime)
The error message on traffic_line with manager not responding has been improved
in a previous commit. The first two issues are more difficult to accommodate.
I'm going to close this one for now, please open a new ticket on the reporting
of modifying non-dynamic configurations via traffic_line.
traffic_line should warn if a command didn't succeed
Key: TS-972
URL: https://issues.apache.org/jira/browse/TS-972
Project: Traffic Server
Issue Type: Improvement
Components: Management API
Affects Versions: 3.1.0, 3.0.1
Reporter: Arno Toell
{{traffic_line}} is a handy tool to manage a traffic server instance. For
example it is possible to retrieve and set configuration settings through
command line like this:
{code}
root@wv-tmp2:/home/at# traffic_line -r proxy.config.http.server_port ; echo $?
81
0
{code}
However, some commans can be set, but aren't effective until the server is
restarted, despite of ATS offering the _-x_ option to flush configuration and
reread new settings:
{code}
root@wv-tmp2:/home/at# traffic_line -s proxy.config.http.server_port -v 80 ;
echo $?
0
root@wv-tmp2:/home/at# traffic_line -x ; echo $?
0
{code}
Trafficserver should possibly warn when setting such settings which aren't
effective until the server is restarted and leave with a non-zero exit status
for _-x_ in such cases.
Moreover {{traffic_line}} does not work at all if the manager is not running:
{code}
# traffic_line -r proxy.config.http.server_port ; echo $?
traffic_line: Variable Not Found
1
{code}
That's all right, but the error message shall be improved telling that. :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1182) Add a flag to LogBuffer's for endian used
[ https://issues.apache.org/jira/browse/TS-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1182. --- Resolution: Won't Fix Fix Version/s: (was: sometime) Meh. Add a flag to LogBuffer's for endian used - Key: TS-1182 URL: https://issues.apache.org/jira/browse/TS-1182 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom After discussions with amc: To support reading logs (either via logcat or log collation) on a box with a different endian from where it was generated, we need to know which endian we generated the log in. Either that, or go back and do the htonl / ntohl conversions always. I favor the flag, since most sane platforms are little endian anyways (certainly all platforms we support are), so why take the cost of the conversions if they are rarely used. This would let us check the endian flag in e.g. the log collation server, and in logcat like tools, and do the conversions only when necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1033: -- Fix Version/s: (was: 5.0.0) 4.2.0 Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 4.2.0 And of course various other places (including InkAPI). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1244) Crash report: cores in Arena::reset
[
https://issues.apache.org/jira/browse/TS-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758218#comment-13758218
]
Leif Hedstrom commented on TS-1244:
---
Manny and Brian: What's the word? Still an issue??
Crash report: cores in Arena::reset
Key: TS-1244
URL: https://issues.apache.org/jira/browse/TS-1244
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.4
Reporter: Manjesh Nilange
Assignee: Brian Geffon
Labels: crash
Fix For: 4.2.0
I have two slightly different stack traces, but both involving Arena::reset
#0 0x003736032a45 in raise () from /lib64/libc.so.6
#1 0x003736034225 in abort () from /lib64/libc.so.6
#2 0x00373606fdfb in __libc_message () from /lib64/libc.so.6
#3 0x003736075716 in malloc_printerr () from /lib64/libc.so.6
#4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
#5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
#6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
#7 0x0050e3e3 in destroy (this=0x2b8c2c1b6b40) at HttpTransact.h:1235
#8 HttpSM::cleanup (this=0x2b8c2c1b6b40) at HttpSM.cc:346
#9 0x0050e719 in HttpSM::destroy (this=0x2b8c2c1b6b40) at
HttpSM.cc:368
#10 0x00515a56 in HttpSM::kill_this (this=0x2b8c2c1b6b40) at
HttpSM.cc:6023
#11 0x00515e08 in HttpSM::main_handler (this=0x2b8c2c1b6b40,
event=2301, data=0x2b8c2c1b8828)
at HttpSM.cc:2452
...
(gdb) f 4
#4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
89ink_free(mem);
(gdb) p mem
$1 = value optimized out
(gdb) f 5
#5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
69xfree(blk);
(gdb) p blk
$2 = value optimized out
(gdb) f 6
#6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
156 blk_free(m_blocks);
(gdb) p m_blocks
$3 = (ArenaBlock *) 0x2b8b9822b870
(gdb) p *m_blocks
$4 = {next = 0x3b323531322e3630, m_heap_end = 0x2554454e2e303225 Address
0x2554454e2e303225 out of bounds,
m_water_level = 0x303225524c433032 Address 0x303225524c433032 out of
bounds, data = 3.5.3072}
(gdb) p *m_blocks-next
Cannot access memory at address 0x3b323531322e3630
It looks m_blocks is corrupted.
and the other stack trace
#3 0x004d03aa in signal_handler (sig=11) at signals.cc:225
#4 signal handler called
#5 blk_free (this=0x2afc58072f88) at Arena.cc:65
#6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
#7 0x0050e3e3 in destroy (this=0x2afc58072f10) at HttpTransact.h:1235
#8 HttpSM::cleanup (this=0x2afc58072f10) at HttpSM.cc:346
#9 0x0050e719 in HttpSM::destroy (this=0x2afc58072f10) at
HttpSM.cc:368
#10 0x00515a56 in HttpSM::kill_this (this=0x2afc58072f10) at
HttpSM.cc:6023
#11 0x00515e08 in HttpSM::main_handler (this=0x2afc58072f10,
event=2301, data=0x2afc58074bf8)
at HttpSM.cc:2452
...
(gdb) f 5
#5 blk_free (this=0x2afc58072f88) at Arena.cc:65
65 size = blk-m_heap_end - blk-data[0];
(gdb) p blk
$1 = value optimized out
(gdb) f 6
#6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
156 blk_free(m_blocks);
(gdb) p m_blocks
$2 = (ArenaBlock *) 0x373439333634
(gdb) p *m_blocks
Cannot access memory at address 0x373439333634
Our environment:
$ uname -a
Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
x86_64 x86_64 x86_64 GNU/Linux
$ file /usr/bin/traffic_server
/usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1113) In case of caching smaller than 1k size of file, It shoud be increase throughput.
[ https://issues.apache.org/jira/browse/TS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758201#comment-13758201 ] Leif Hedstrom commented on TS-1113: --- I don't know what to make out of this. I measure 160,000 QPS out of cache on 1KB small objects. Going to close this for now, please reopen if it's still an issue. In case of caching smaller than 1k size of file, It shoud be increase throughput. --- Key: TS-1113 URL: https://issues.apache.org/jira/browse/TS-1113 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.1.1 Reporter: Eric Ahn Priority: Minor Fix For: sometime If there are a lot 1k sized objects, It's not good performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1311) Range hit in cluster will crash server
[
https://issues.apache.org/jira/browse/TS-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758223#comment-13758223
]
Leif Hedstrom commented on TS-1311:
---
Is this still an issue in 4.0.1 ?
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
Fix For: 4.2.0
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1113) In case of caching smaller than 1k size of file, It shoud be increase throughput.
[ https://issues.apache.org/jira/browse/TS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1113: -- Fix Version/s: (was: sometime) In case of caching smaller than 1k size of file, It shoud be increase throughput. --- Key: TS-1113 URL: https://issues.apache.org/jira/browse/TS-1113 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.1.1 Reporter: Eric Ahn Priority: Minor If there are a lot 1k sized objects, It's not good performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1113) In case of caching smaller than 1k size of file, It shoud be increase throughput.
[ https://issues.apache.org/jira/browse/TS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1113. --- Resolution: Won't Fix In case of caching smaller than 1k size of file, It shoud be increase throughput. --- Key: TS-1113 URL: https://issues.apache.org/jira/browse/TS-1113 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.1.1 Reporter: Eric Ahn Priority: Minor If there are a lot 1k sized objects, It's not good performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1327) Crash report: thread_allocUnixNetVConnection (this=0x1162060, t=0x0), in HttpSM::do_http_server_open
[
https://issues.apache.org/jira/browse/TS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758224#comment-13758224
]
Leif Hedstrom commented on TS-1327:
---
Alan / ming_zym? Can we close this ?
Crash report: thread_allocUnixNetVConnection (this=0x1162060, t=0x0), in
HttpSM::do_http_server_open
--
Key: TS-1327
URL: https://issues.apache.org/jira/browse/TS-1327
Project: Traffic Server
Issue Type: Bug
Components: HTTP, Network
Affects Versions: 3.3.0
Environment: tree 3.2.x x86_64 cluster type=1, with some patches in
cluster
Reporter: Zhao Yongming
Assignee: Alan M. Carroll
Fix For: 4.2.0
{code}
Core was generated by `/usr/bin/traffic_server -M --httpport
8080:fd=12,80:fd=13'.
Program terminated with signal 11, Segmentation fault.
#0 thread_allocUnixNetVConnection (this=0x1162060, t=0x0) at
../../iocore/eventsystem/I_ProxyAllocator.h:50
50if (l.freelist) {
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64
libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) bt
#0 thread_allocUnixNetVConnection (this=0x1162060, t=0x0) at
../../iocore/eventsystem/I_ProxyAllocator.h:50
#1 UnixNetProcessor::allocateThread (this=0x1162060, t=0x0) at
UnixNetProcessor.cc:474
#2 0x00645c91 in UnixNetProcessor::connect_re_internal
(this=0x1162060, cont=value optimized out, target=0x2aba94506d88,
opt=0x2aba4dc8f980) at UnixNetProcessor.cc:200
#3 0x00525587 in connect_re (this=0x2aba945066f0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:89
#4 HttpSM::do_http_server_open (this=0x2aba945066f0, raw=value optimized
out) at HttpSM.cc:4333
#5 0x005291f8 in HttpSM::set_next_state (this=0x2aba945066f0) at
HttpSM.cc:6591
#6 0x0052a128 in HttpSM::state_send_server_request_header
(this=0x2aba945066f0, event=104, data=0x2aba90010da8) at HttpSM.cc:1932
#7 0x005202b8 in HttpSM::main_handler (this=0x2aba945066f0,
event=104, data=0x2aba90010da8) at HttpSM.cc:2463
#8 0x00648651 in handleEvent (event=value optimized out,
nh=0x2aba4d4901e8, vc=0x2aba90010ca0)
at ../../iocore/eventsystem/I_Continuation.h:146
#9 read_signal_and_update (event=value optimized out, nh=0x2aba4d4901e8,
vc=0x2aba90010ca0) at UnixNetVConnection.cc:138
#10 read_signal_done (event=value optimized out, nh=0x2aba4d4901e8,
vc=0x2aba90010ca0) at UnixNetVConnection.cc:168
#11 0x0064abf5 in read_from_net (nh=0x2aba4d4901e8,
vc=0x2aba90010ca0, thread=value optimized out) at UnixNetVConnection.cc:291
#12 0x00643c6a in NetHandler::mainNetEvent (this=0x2aba4d4901e8,
event=value optimized out, e=value optimized out)
at UnixNet.cc:372
#13 0x006698a4 in handleEvent (this=0x2aba4d48d010, e=0x1b0fdc0,
calling_code=5) at I_Continuation.h:146
#14 EThread::process_event (this=0x2aba4d48d010, e=0x1b0fdc0, calling_code=5)
at UnixEThread.cc:142
#15 0x0066a233 in EThread::execute (this=0x2aba4d48d010) at
UnixEThread.cc:264
#16 0x00668b72 in spawn_thread_internal (a=0x1ac9640) at Thread.cc:88
#17 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#18 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb)
(gdb) f 2
#2 0x00645c91 in UnixNetProcessor::connect_re_internal
(this=0x1162060, cont=value optimized out, target=0x2aba94506d88,
opt=0x2aba4dc8f980) at UnixNetProcessor.cc:200
200 UnixNetVConnection *vc = allocateThread(t);
(gdb) l
195 sockaddr const* target,
196 NetVCOptions * opt
197 ) {
198 ProxyMutex *mutex = cont-mutex;
199 EThread *t = mutex-thread_holding;
200 UnixNetVConnection *vc = allocateThread(t);
201
202 if (opt)
203 vc-options = *opt;
204 else
(gdb) p *t
Cannot access memory at address 0x0
(gdb)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1391) Crash report: cop may crash during spawn failed manager
[
https://issues.apache.org/jira/browse/TS-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1391:
--
Fix Version/s: (was: 4.2.0)
Crash report: cop may crash during spawn failed manager
---
Key: TS-1391
URL: https://issues.apache.org/jira/browse/TS-1391
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.0.2
Reporter: Zhao Yongming
{code}
Aug 3 16:35:51 cache163 kernel: [4226777.248341] [ET_NET 7][20675]: segfault
at 1 ip 00380d0479e7 sp 2b393b968300 error 4 in
libc-2.12.so[380d00+197000]
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} FATAL:
(last system error 104: Connection reset by peer)
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} ERROR:
(last system error 32: Broken pipe)
Aug 3 16:36:13 cache163 traffic_cop[20651]: (test) read failed [104
'Connection reset by peer']
Aug 3 16:36:13 cache163 traffic_cop[20651]: server heartbeat failed [1]
Aug 3 16:36:13 cache163 traffic_cop[20651]: cop received child status signal
[20653 35584]
Aug 3 16:36:13 cache163 traffic_cop[20651]: traffic_manager not running,
making sure traffic_server is dead
Aug 3 16:36:13 cache163 traffic_cop[20651]: spawning traffic_manager
Aug 3 16:36:13 cache163 traffic_manager[9091]: NOTE: --- Manager Starting ---
Aug 3 16:36:13 cache163 traffic_manager[9091]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.2 - (build # 63010 on Jul 30 2012 at
10:42:45)
Aug 3 16:36:13 cache163 traffic_manager[9091]: {0x7fabbb5c97e0} STATUS:
opened /var/log/trafficserver/manager.log
Aug 3 16:36:23 cache163 traffic_cop[20651]: (cli test) unable to retrieve
manager_binary
Aug 3 16:36:36 cache163 traffic_server[9135]: NOTE: --- Server Starting ---
Aug 3 16:36:36 cache163 traffic_server[9135]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.0.2 - (build # 63010 on Jul 30 2012 at
10:43:07)
Aug 3 16:36:36 cache163 traffic_server[9135]: {0x2b247888d740} STATUS:
opened /var/log/trafficserver/diags.log
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1333) make sure all records directives traffic_line nice
[ https://issues.apache.org/jira/browse/TS-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1333: -- Fix Version/s: (was: 5.0.0) 4.2.0 Assignee: Leif Hedstrom make sure all records directives traffic_line nice -- Key: TS-1333 URL: https://issues.apache.org/jira/browse/TS-1333 Project: Traffic Server Issue Type: Task Components: Management Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: Leif Hedstrom Fix For: 4.2.0 the following options need to check: proxy.config.net.defer_accept -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1411) Seg faulting during log rotation
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1411:
-
Assignee: Yunkai Zhang (was: Leif Hedstrom)
Seg faulting during log rotation
Key: TS-1411
URL: https://issues.apache.org/jira/browse/TS-1411
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: RHEL 6.2 x86_64
Reporter: David Carlin
Assignee: Yunkai Zhang
Fix For: 4.2.0
Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include
the unmapped URL and the user agent string:
%cqtq %ttms %chi %crc/%pssc %psql %cqhm %cquc %caun
%phr/%pqsn %psct %xid %cquuc \%{User-Agent}cqh\
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones
seem to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x383f00f500]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x48)[0x58a118]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x58c3f0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x59d5a2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x399)[0x5a7ed9]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x673871]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x6756e7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66e076]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696ce4]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697673]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x383f007851]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1411) Seg faulting during log rotation
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758228#comment-13758228
]
Leif Hedstrom commented on TS-1411:
---
Is this still an issue ?
Seg faulting during log rotation
Key: TS-1411
URL: https://issues.apache.org/jira/browse/TS-1411
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: RHEL 6.2 x86_64
Reporter: David Carlin
Assignee: Leif Hedstrom
Fix For: 4.2.0
Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include
the unmapped URL and the user agent string:
%cqtq %ttms %chi %crc/%pssc %psql %cqhm %cquc %caun
%phr/%pqsn %psct %xid %cquuc \%{User-Agent}cqh\
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones
seem to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x383f00f500]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x48)[0x58a118]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x58c3f0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x59d5a2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x399)[0x5a7ed9]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x673871]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x6756e7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x286)[0x66e076]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696ce4]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697673]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x383f007851]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1391) Crash report: cop may crash during spawn failed manager
[
https://issues.apache.org/jira/browse/TS-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1391.
---
Resolution: Duplicate
Closing as duplicate, please reopen if this is not the case. Thanks Kamil!
Crash report: cop may crash during spawn failed manager
---
Key: TS-1391
URL: https://issues.apache.org/jira/browse/TS-1391
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.0.2
Reporter: Zhao Yongming
{code}
Aug 3 16:35:51 cache163 kernel: [4226777.248341] [ET_NET 7][20675]: segfault
at 1 ip 00380d0479e7 sp 2b393b968300 error 4 in
libc-2.12.so[380d00+197000]
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} FATAL:
(last system error 104: Connection reset by peer)
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Aug 3 16:36:13 cache163 traffic_manager[20653]: {0x7fc6760f97e0} ERROR:
(last system error 32: Broken pipe)
Aug 3 16:36:13 cache163 traffic_cop[20651]: (test) read failed [104
'Connection reset by peer']
Aug 3 16:36:13 cache163 traffic_cop[20651]: server heartbeat failed [1]
Aug 3 16:36:13 cache163 traffic_cop[20651]: cop received child status signal
[20653 35584]
Aug 3 16:36:13 cache163 traffic_cop[20651]: traffic_manager not running,
making sure traffic_server is dead
Aug 3 16:36:13 cache163 traffic_cop[20651]: spawning traffic_manager
Aug 3 16:36:13 cache163 traffic_manager[9091]: NOTE: --- Manager Starting ---
Aug 3 16:36:13 cache163 traffic_manager[9091]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.2 - (build # 63010 on Jul 30 2012 at
10:42:45)
Aug 3 16:36:13 cache163 traffic_manager[9091]: {0x7fabbb5c97e0} STATUS:
opened /var/log/trafficserver/manager.log
Aug 3 16:36:23 cache163 traffic_cop[20651]: (cli test) unable to retrieve
manager_binary
Aug 3 16:36:36 cache163 traffic_server[9135]: NOTE: --- Server Starting ---
Aug 3 16:36:36 cache163 traffic_server[9135]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.0.2 - (build # 63010 on Jul 30 2012 at
10:43:07)
Aug 3 16:36:36 cache163 traffic_server[9135]: {0x2b247888d740} STATUS:
opened /var/log/trafficserver/diags.log
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-794) ssl session reuse can not pass sslswamp testing
[
https://issues.apache.org/jira/browse/TS-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758178#comment-13758178
]
Leif Hedstrom commented on TS-794:
--
ming_zym: please decide upon this. Is it still an issue?
ssl session reuse can not pass sslswamp testing
---
Key: TS-794
URL: https://issues.apache.org/jira/browse/TS-794
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.8
Environment: sslv3 tlsv1
Reporter: Zhao Yongming
Labels: A
Fix For: 4.2.0
When I testing from the patches from qianshi, for TS-718, the ssl session
resumption looks perfect, but still can not pass the sslswamp testing, it
looks like the second and later request will not be handled from the https
connection. it may be a issue for https handler, here is some information
testing from sslswamp:
{code}
[root@unknown-10-62-163-x ~]# sslswamp -connect IP:10.32.21.75:443 -num 1
-count 4 -session srrr -update 10 -request GET
https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg
HTTP/1.0\r\n\r\n -session_ids -nologo -expect 64000 -sslmeth tlsv1
No 'cacert' supplied, trying defaults ... '/usr/share/swamp/CA.pem' found.
no client cert provided, continuing anyway.
Certificate verification failed, probably a self-signed server cert *or*
the signing CA cert is not trusted by us (hint: use '-CAfile').
This message will only be printed once
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 0 failed, resumes(+1,-0) 0.01
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
240 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 3 failed, resumes(+3,-0) 0.00
ops/sec
{code}
the log from traffic.out:
{code}
[May 20 18:30:59.544] Manager {140339380279072} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '10'
[May 20 18:30:59.544] Manager {140339380279072} NOTE: [Alarms::signalAlarm]
Server Process born
[May 20 18:31:00.564] {47816222021376} STATUS: opened
/var/log/trafficserver/diags.log
[May 20 18:31:00.613] {47816222021376} NOTE: updated diags config
[May 20 18:31:00.648] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:00.784] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:01.237] Server {47816222021376} DEBUG: (ssl)
[SSLNetProcessor::initSSLServerCTX] set the callback for external session
caching.
[May 20 18:31:01.412] Server {47816222021376} NOTE: logging initialized[7],
logging_mode = 3
[May 20 18:31:01.669] Server {47816222021376} NOTE: traffic server running
[May 20 18:31:01.793] Server {47816237516544} NOTE: cache enabled
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
[ssl_callback_NewSessionCacheEntry] store id
[D91C5F59EB43C5E8864303B449B9B1673D3218300EE03FDC4790125A7BCB521D]'s session
into cache.
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=82
SSL Read
GET https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg HTTP/1.0
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read=82
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4014
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[jira] [Closed] (TS-686) Change location in the APIs to be type specific
[ https://issues.apache.org/jira/browse/TS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-686. - Resolution: Unresolved I don't think it is worth the effort at this time and time would be better spend on getting the c++ api finished off. This would definitely break binary compatibility Change location in the APIs to be type specific --- Key: TS-686 URL: https://issues.apache.org/jira/browse/TS-686 Project: Traffic Server Issue Type: Improvement Components: TS API Affects Versions: 2.1.6 Reporter: Bryan Call Priority: Minor Fix For: sometime Change arguments for APIs to use type specific combinations of buffer and location instead of having generic types (e.g., TSMBuffer, TSMLoc) that can be interchanged. Leif and I talked about this more after I sent and email to dev@ and we agreed that combining the buffer and location would be better unless there are a lot of APIs that require then to passed in separately. Looking over the APIs I don't think this is the case. Also, we talked about possibly having request and response being the same type, so there wouldn't be two version of some of the APIs (e.g., TSHttpHdrUrlGet()) Parts of my email to dev@: Looking at the three APIs below it is hard to tell the location/offset really point to: tsapi TSReturnCode TSHttpTxnClientReqGet(TSHttpTxn txnp, TSMBuffer* bufp, TSMLoc* offset); tsapi TSReturnCode TSHttpHdrUrlGet(TSMBuffer bufp, TSMLoc offset, TSMLoc* locp); tsapi const char* TSUrlSchemeGet(TSMBuffer bufp, TSMLoc offset, int *length); In a specific case that happened last week a person was taking bufp and offset from TSHttpTxnClientReqGet() and passing the values to TSUrlSchemeGet(). Since it didn't give him compile errors he only saw the problem when the server was under load and it would core dump. One way to fix this would be to change locations to specific types. If we want to take it a step further the buffer and location could be combined and given a specific type simplifying the APIs. Example of combining buffer and location and making specific types (IMO cleaner): tsapi TSReturnCode TSHttpTxnClientReqGet(TSHttpTxn txnp, TSRequest *request); tsapi TSReturnCode TSHttpHdrUrlGet(TSRequest request, TSUrl *url); tsapi const char* TSUrlSchemeGet(TSUrl url, int *length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2177) FeatureAPIHooks code needs better comments, naming.
[ https://issues.apache.org/jira/browse/TS-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758185#comment-13758185 ] ASF subversion and git services commented on TS-2177: - Commit 6da47d5c43419d2d54429d9c777f5e40c774c41a in branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6da47d5 ] TS-2177: Add invoke utility method to APIHooks. FeatureAPIHooks code needs better comments, naming. --- Key: TS-2177 URL: https://issues.apache.org/jira/browse/TS-2177 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 4.1.0 Add comments to the FeatureAPIHook code. Rename template parameter MAX_ID to N so the name corresponds to the use of the parameter. Add a couple of utility methods for future use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-858) traffic_server segmentation_fault when cache storage value is below 65M
[
https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758187#comment-13758187
]
ASF subversion and git services commented on TS-858:
Commit 182405352dd62726e532135bad155df57e5d8014 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1824053 ]
TS-858 Updated the docs to 128MB examples
This avoids the confusion of examples being smaller than
the minimum disk cache size we have.
traffic_server segmentation_fault when cache storage value is below 65M
---
Key: TS-858
URL: https://issues.apache.org/jira/browse/TS-858
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.0.0
Environment: Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.0.0
specify the storage as var/trafficserver 64M in the storage.conf,
traffic_server will core dump upon launch, the following is the stack trace:
{noformat}
FATAL: Cache.cc:2293: failed assert `dpb dpb-len == (uint64_t)b`
traffic_server - STACK TRACE:
traffic_server(ink_fatal_va+0x8e)[0x82ef221]
traffic_server(ink_fatal+0x1e)[0x82ef252]
traffic_server(_ink_assert+0x90)[0x82eeb6c]
traffic_server(cplist_reconfigure()+0x2fd)[0x8283054]
traffic_server(CacheProcessor::diskInitialized()+0x19b)[0x827b7d1]
traffic_server(CacheDisk::openDone(int, void*)+0x40)[0x8291142]
traffic_server(CacheDisk::clearDone(int, void*)+0xcc)[0x8290eb2]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x2c)[0x82862c8]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(EThread::process_event(Event*, int)+0x10e)[0x82e83f2]
traffic_server(EThread::execute()+0xa6)[0x82e862a]
traffic_server[0x82e74b1]
/lib/libpthread.so.0[0x658e99]
/lib/libc.so.6(clone+0x5e)[0x59ed2e]
{noformat}
It will core dump everytime, if the cache size is set to 65M, traffic_server
will launch fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-858) traffic_server segmentation_fault when cache storage value is below 65M
[
https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-858.
--
Resolution: Fixed
Fix Version/s: (was: 5.0.0)
4.1.0
I added this to the documentation.
traffic_server segmentation_fault when cache storage value is below 65M
---
Key: TS-858
URL: https://issues.apache.org/jira/browse/TS-858
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.0.0
Environment: Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 4.1.0
specify the storage as var/trafficserver 64M in the storage.conf,
traffic_server will core dump upon launch, the following is the stack trace:
{noformat}
FATAL: Cache.cc:2293: failed assert `dpb dpb-len == (uint64_t)b`
traffic_server - STACK TRACE:
traffic_server(ink_fatal_va+0x8e)[0x82ef221]
traffic_server(ink_fatal+0x1e)[0x82ef252]
traffic_server(_ink_assert+0x90)[0x82eeb6c]
traffic_server(cplist_reconfigure()+0x2fd)[0x8283054]
traffic_server(CacheProcessor::diskInitialized()+0x19b)[0x827b7d1]
traffic_server(CacheDisk::openDone(int, void*)+0x40)[0x8291142]
traffic_server(CacheDisk::clearDone(int, void*)+0xcc)[0x8290eb2]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x2c)[0x82862c8]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(EThread::process_event(Event*, int)+0x10e)[0x82e83f2]
traffic_server(EThread::execute()+0xa6)[0x82e862a]
traffic_server[0x82e74b1]
/lib/libpthread.so.0[0x658e99]
/lib/libc.so.6(clone+0x5e)[0x59ed2e]
{noformat}
It will core dump everytime, if the cache size is set to 65M, traffic_server
will launch fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758237#comment-13758237 ] Leif Hedstrom commented on TS-1486: --- Lets do this? Igor? drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: 4.1.0 We should drop Solaris Studio support for the 3.4 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-777) Increasing logbuffer size makes us drop log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758173#comment-13758173 ] Leif Hedstrom commented on TS-777: -- Yunkai: Is this still an issue? Increasing logbuffer size makes us drop log entries - Key: TS-777 URL: https://issues.apache.org/jira/browse/TS-777 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 2.1.8 Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 4.2.0 Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB makes us start losing log entries. This is bad, since increasing this setting could be a way to increase performance for busy systems. I've for now set the defaults to 16KB, which seems to be stable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1493) TShtrime() returning negative value
[ https://issues.apache.org/jira/browse/TS-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13758248#comment-13758248 ] Leif Hedstrom commented on TS-1493: --- Ouch, we still have this here. Bianca, is this still an issue? TShtrime() returning negative value --- Key: TS-1493 URL: https://issues.apache.org/jira/browse/TS-1493 Project: Traffic Server Issue Type: Bug Components: Core Reporter: bianca cooper Fix For: 5.0.0 calling TShrtime function after TS_EVENT_HTTP_TXN_CLOSE (and before reenable the transaction) sometimes returns negative number calling the same function in other places in code always returns positive number. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1489) libtool: install: warning: relinking `libtsmgmt.la'
[ https://issues.apache.org/jira/browse/TS-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1489. --- Resolution: Duplicate Fix Version/s: (was: 5.0.0) libtool: install: warning: relinking `libtsmgmt.la' --- Key: TS-1489 URL: https://issues.apache.org/jira/browse/TS-1489 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 3.3.0 Reporter: Zhao Yongming this is the last warning in my buildbot, we should find out and fix it, then build bot does not bother us anymore :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1490) When browers send requests with Connection: keep-alive header .ESI will result in an empty response
[ https://issues.apache.org/jira/browse/TS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1490: - Assignee: Kit Chan Kit, can you take a look at this please? Is it still an issue? If not, remove fix version and close it. When browers send requests with Connection: keep-alive header .ESI will result in an empty response - Key: TS-1490 URL: https://issues.apache.org/jira/browse/TS-1490 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.3.4 Environment: centos 6 x86_64 build from git Reporter: bettydramit Assignee: Kit Chan Fix For: 5.0.0 When browers send requests with Connection: keep-alive header .ESI will result in an empty response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
