[jira] [Created] (TS-3022) double free or corruption (!prev)
bettydramit created TS-3022:
---
Summary: double free or corruption (!prev)
Key: TS-3022
URL: https://issues.apache.org/jira/browse/TS-3022
Project: Traffic Server
Issue Type: Bug
Reporter: bettydramit
Centos 6 x86_64 gitmaster
Enable ocsp
config set
{code}
CONFIG proxy.config.ssl.ocsp.enabled INT 1
CONFIG proxy.config.ssl.ocsp.update_period INT 60
{code}
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x02af8be0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
/lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
/usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
/usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
/usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
/usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
/usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
/usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
/usr/bin/traffic_server[0x73eb5a]
/lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2902) Allow POST requests without a Content-Length header
[
https://issues.apache.org/jira/browse/TS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101908#comment-14101908
]
Masakazu Kitajo commented on TS-2902:
-
[~bcall]
I tested again with latest source code on master branch, and it works for me.
Your test shows status code 400. It should be 411 if you apply the patch as is.
Would you test it again?
Here are my tests:
{noformat}
$ ./bin/traffic_line -r proxy.config.http.post.check.content_length.enabled
1
$ curl -v -s -d@foo -x localhost:8080 -H Content-Length: -o /dev/null
http://www.yahoo.co.jp/;
* About to connect() to proxy localhost port 8080 (#0)
* Trying 127.0.0.1... connected
POST http://www.yahoo.co.jp/ HTTP/1.1
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: www.yahoo.co.jp
Accept: */*
Proxy-Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 411 Content Length Required
Date: Tue, 19 Aug 2014 05:43:36 GMT
Connection: close
Server: ATS/5.1.0
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Content-Length: 277
{ [data not shown]
* Closing connection #0
{noformat}
{noformat}
$ ./bin/traffic_line -r proxy.config.http.post.check.content_length.enabled
0
$ curl -v -s -d@foo -x localhost:8080 -H Content-Length: -o /dev/null
http://www.yahoo.co.jp/;
* About to connect() to proxy localhost port 8080 (#0)
* Trying 127.0.0.1... connected
POST http://www.yahoo.co.jp/ HTTP/1.1
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: www.yahoo.co.jp
Accept: */*
Proxy-Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: ATS/5.1.0
Date: Tue, 19 Aug 2014 05:43:21 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 4058
P3P: policyref=http://privacy.yahoo.co.jp/w3c/p3p_jp.xml;, CP=CAO DSP COR
CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi
IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: -1
Pragma: no-cache
X-XRDS-Location: https://open.login.yahooapis.jp/openid20/www.yahoo.co.jp/xrds
Vary: Accept-Encoding
Content-Encoding: gzip
Age: 0
Proxy-Connection: keep-alive
{ [data not shown]
* Connection #0 to host localhost left intact
* Closing connection #0
{noformat}
Allow POST requests without a Content-Length header
---
Key: TS-2902
URL: https://issues.apache.org/jira/browse/TS-2902
Project: Traffic Server
Issue Type: Improvement
Reporter: Masakazu Kitajo
Assignee: Bryan Call
Labels: review
Fix For: 5.1.0
Attachments: make_it_configuarable.patch
I get *400* Content Length Required when user agents send a POST request
that doesn't contain any body data without a Content-Length header.
(The header is omitted because the length is zero, I think)
According to RFC2730 Section 3.3.2, presence of Content-Length is not MUST.
http://tools.ietf.org/html/rfc7230#section-3.3.2
{quote}
A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body.
{quote}
Also according to section 3.3.3, a server are allowed to reject similar
request with 411 Length Required, but not *400*.
http://tools.ietf.org/html/rfc7230#section-3.3.2
{quote}
A server MAY reject a request that contains a message body but not a
Content-Length by responding with 411 (Length Required).
{quote}
Traffic Server should accept the requests, no body data without
Content-Length header, or reject it with *411*. I think the former one is
better for interoperability.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3022) double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101973#comment-14101973
]
bettydramit commented on TS-3022:
-
gdb info
{code}
(gdb) bt
#0 0x2ba78af74925 in raise () from /lib64/libc.so.6
#1 0x2ba78af76105 in abort () from /lib64/libc.so.6
#2 0x2ba78afb2837 in __libc_message () from /lib64/libc.so.6
#3 0x2ba78afb8166 in malloc_printerr () from /lib64/libc.so.6
#4 0x2ba78afbac93 in _int_free () from /lib64/libc.so.6
#5 0x2ba7888bd0ad in CRYPTO_free () from /usr/lib64/libcrypto.so.10
#6 0x2ba7888beada in ?? () from /usr/lib64/libcrypto.so.10
#7 0x2ba78862be7e in SSL_CTX_free () from /usr/lib64/libssl.so.10
#8 0x0072c579 in SSLContextStorage::~SSLContextStorage
(this=0x2a1a940, __in_chrg=value optimized out) at SSLCertLookup.cc:216
#9 0x0072c6e9 in ~SSLCertLookup (this=0x2a1a910, __in_chrg=value
optimized out) at SSLCertLookup.cc:104
#10 SSLCertLookup::~SSLCertLookup (this=0x2a1a910, __in_chrg=value optimized
out) at SSLCertLookup.cc:105
#11 0x00665e67 in ConfigInfoReleaser::handle_event
(this=0x2aaae407c060) at ProxyConfig.cc:106
#12 0x0073f8af in handleEvent (this=0x2ba78d820010, e=0x2aab21baeea0,
calling_code=2) at I_Continuation.h:146
#13 EThread::process_event (this=0x2ba78d820010, e=0x2aab21baeea0,
calling_code=2) at UnixEThread.cc:144
#14 0x00740263 in EThread::execute (this=0x2ba78d820010) at
UnixEThread.cc:223
#15 0x0073ec4a in spawn_thread_internal (a=0x2622710) at Thread.cc:88
#16 0x2ba78a0349d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2ba78b02ab6d in clone () from /lib64/libc.so.6
(gdb)
{code}
double free or corruption (!prev)
-
Key: TS-3022
URL: https://issues.apache.org/jira/browse/TS-3022
Project: Traffic Server
Issue Type: Bug
Reporter: bettydramit
Centos 6 x86_64 gitmaster
Enable ocsp
config set
{code}
CONFIG proxy.config.ssl.ocsp.enabled INT 1
CONFIG proxy.config.ssl.ocsp.update_period INT 60
{code}
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x02af8be0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
/lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
/usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
/usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
/usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
/usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
/usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
/usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
/usr/bin/traffic_server[0x73eb5a]
/lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3006: --- Attachment: openssl-sni.patch Tested against openssl version 1.0.1f Augment SNI callback processing --- Key: TS-3006 URL: https://issues.apache.org/jira/browse/TS-3006 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Attachments: openssl-sni.patch When starting to proxy a SSL connection, it would be nice to have the servername available for decision making. The SNI callback gives us this information. The SNI callback is currently used by core. Plugins may also want to execute their own logic at the SNI callback. They can do that now using the openssl calls directly, but that would remove the core SNI callback processing. We should add plugin calls to register code to be executed in the SNI callback for a connection. The plugin code would be executed after the core SNI callback logic. In addition, there are scenarios when it would be useful to change how things are processed after learning the server name, e.g., decide to blind tunnel instead of proxy tunnel (see TS-2956) or perform some different certificate calculations. Performing these extended operations are not feasible within the SNI callback. Instead we want to break out of the SSL_accept() and perform some other logic. Openssl as it stands does not allow to break out of the openssl handshake from the SNI callback short of issuing an error (which would send an error message back to the client). We have created a patch that adds a new return which breaks out of the SSL_accept() with a non-error but non-complete return (like needs to read). If that patch was present, the core logic could be extended to adjust processing. In the blind tunnel case, the core logic could resend the first message (client hello) directly to the original server and move into the blind tunnel processing for the connection. In a certificate case, the core logic or some plugin logic could perform some certificate calculations and then try the SSL_accept() again at some later point in time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-3006) Augment SNI callback processing
[ https://issues.apache.org/jira/browse/TS-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102228#comment-14102228 ] Susan Hinrichs edited comment on TS-3006 at 8/19/14 2:14 PM: - The patch openssl-sni.patch as been tested against openssl version 1.0.1f. It adds the ability discussed in earlier comments to return a value from an SNI callback and stop the SSL handshake processing in SSL_accept. was (Author: shinrich): Tested against openssl version 1.0.1f Augment SNI callback processing --- Key: TS-3006 URL: https://issues.apache.org/jira/browse/TS-3006 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Attachments: openssl-sni.patch When starting to proxy a SSL connection, it would be nice to have the servername available for decision making. The SNI callback gives us this information. The SNI callback is currently used by core. Plugins may also want to execute their own logic at the SNI callback. They can do that now using the openssl calls directly, but that would remove the core SNI callback processing. We should add plugin calls to register code to be executed in the SNI callback for a connection. The plugin code would be executed after the core SNI callback logic. In addition, there are scenarios when it would be useful to change how things are processed after learning the server name, e.g., decide to blind tunnel instead of proxy tunnel (see TS-2956) or perform some different certificate calculations. Performing these extended operations are not feasible within the SNI callback. Instead we want to break out of the SSL_accept() and perform some other logic. Openssl as it stands does not allow to break out of the openssl handshake from the SNI callback short of issuing an error (which would send an error message back to the client). We have created a patch that adds a new return which breaks out of the SSL_accept() with a non-error but non-complete return (like needs to read). If that patch was present, the core logic could be extended to adjust processing. In the blind tunnel case, the core logic could resend the first message (client hello) directly to the original server and move into the blind tunnel processing for the connection. In a certificate case, the core logic or some plugin logic could perform some certificate calculations and then try the SSL_accept() again at some later point in time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3022) double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3022:
Component/s: SSL
Priority: Blocker (was: Major)
Fix Version/s: 5.1.0
For 5.1
double free or corruption (!prev)
-
Key: TS-3022
URL: https://issues.apache.org/jira/browse/TS-3022
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: bettydramit
Priority: Blocker
Fix For: 5.1.0
Centos 6 x86_64 gitmaster
Enable ocsp
config set
{code}
CONFIG proxy.config.ssl.ocsp.enabled INT 1
CONFIG proxy.config.ssl.ocsp.update_period INT 60
{code}
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x02af8be0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
/lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
/usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
/usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
/usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
/usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
/usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
/usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
/usr/bin/traffic_server[0x73eb5a]
/lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2902) Allow POST requests without a Content-Length header
[
https://issues.apache.org/jira/browse/TS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102426#comment-14102426
]
ASF subversion and git services commented on TS-2902:
-
Commit db3de1894901d4ec9e2bc7983dac48941b104ffc in trafficserver's branch
refs/heads/master from [~maskit]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=db3de18 ]
TS-2902: Allow POST requests without a Content-Length header
Allow POST requests without a Content-Length header
---
Key: TS-2902
URL: https://issues.apache.org/jira/browse/TS-2902
Project: Traffic Server
Issue Type: Improvement
Reporter: Masakazu Kitajo
Assignee: Bryan Call
Labels: review
Fix For: 5.1.0
Attachments: make_it_configuarable.patch
I get *400* Content Length Required when user agents send a POST request
that doesn't contain any body data without a Content-Length header.
(The header is omitted because the length is zero, I think)
According to RFC2730 Section 3.3.2, presence of Content-Length is not MUST.
http://tools.ietf.org/html/rfc7230#section-3.3.2
{quote}
A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body.
{quote}
Also according to section 3.3.3, a server are allowed to reject similar
request with 411 Length Required, but not *400*.
http://tools.ietf.org/html/rfc7230#section-3.3.2
{quote}
A server MAY reject a request that contains a message body but not a
Content-Length by responding with 411 (Length Required).
{quote}
Traffic Server should accept the requests, no body data without
Content-Length header, or reject it with *411*. I think the former one is
better for interoperability.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102486#comment-14102486
]
ASF subversion and git services commented on TS-2095:
-
Commit 957e60b917bd80ce9ae1de3fdc7e47afaa8cfc08 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=957e60b ]
TS-2095: autoconf warnings related to unordered_map
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.1.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-2095.
Resolution: Fixed
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.1.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-3016) High CPU in 5.0
[
https://issues.apache.org/jira/browse/TS-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-3016.
--
Resolution: Invalid
This is how PFS should be implemented and how other server implement PFS.
High CPU in 5.0
---
Key: TS-3016
URL: https://issues.apache.org/jira/browse/TS-3016
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Fix For: 5.1.0
After 5.0 roll out, our production systems are noticing much higher cpu
compared to pre-upgrade ats4 cpu usage.
For example, on some of our hosts running 8 hosts, below is the comparison
before and after the upgade:
{code}
cpu %util: 88.7% (version: ats5)
cpu %util: 70% (version: ats4)
{code}
Running perf top on traffic_server shows most CPU spent in SSL api calls,
initially causing us to suspect any SSL related changes. However, after some
analysis, it looks like the issue might be caused by the changes made in
TS-1365. After reverting the changes in TS-1365, the CPU usage comes back to
pre-upgrade levels again.
{code}
ats5:
--
Samples: 374K of event 'cycles', Event count (approx.): 29126701697
26.44% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
16.26% libcrypto.so.1.0.1e [.] bn_mul_mont --
6.74% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
4.95% libcrypto.so.1.0.1e [.] BN_usub
1.54% libcrypto.so.1.0.1e [.] sha256_block_data_order
1.37% libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery
80.89 libcrypto.so.1.0.1e
7.09 traffic_server
5.02 [kernel]
2.71 libc-2.12.so
0.59 libpthread-2.12.so
0.42 libssl.so.1.0.1e
0.32 libtsutil.so.5
0.32 [bnx2]
0.02 libstdc++.so.6.0.13
0.02 libpcre.so.0.0.1
0.01 quick_filter.so
0.01 libtcl8.5.so
0.01 librt-2.12.so
0.01 [kernel].vsyscall_fn
0.01 [kernel].vsyscall_1
0 regex_remap.so
0 libresolv-2.12.so
0 libgtlocip.so.1.7.4.B86
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [kernel].vsyscall_0
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
ats4:
-
Samples: 249K of event 'cycles', Event count (approx.): 18282595621
39.34% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
10.23% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
6.25% libcrypto.so.1.0.1e [.] bn_mul_mont --
2.19% libcrypto.so.1.0.1e [.] sha256_block_data_order
2.03% libcrypto.so.1.0.1e [.] BN_usub
1.50% [kernel] [k] find_busiest_group
1.08% libcrypto.so.1.0.1e [.] sha1_block_data_order_ssse3
80.93 libcrypto.so.1.0.1e
6.9 [kernel]
4.96 traffic_server
3 libc-2.12.so
0.84 libpthread-2.12.so
0.81 libssl.so.1.0.1e
0.38 [bnx2]
0.32 libtsutil.so.4
0.02 libtcl8.5.so
0.02 librt-2.12.so
0.02 libpcre.so.0.0.1
0.02 [kernel].vsyscall_fn
0.01 quick_filter.so
0.01 [kernel].vsyscall_1
0.01 [kernel].vsyscall_0
0 regex_remap.so
0 libstdc++.so.6.0.13
0 libresolv-2.12.so
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-3016) High CPU in 5.0
[
https://issues.apache.org/jira/browse/TS-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102491#comment-14102491
]
Bryan Call edited comment on TS-3016 at 8/19/14 5:24 PM:
-
This is how PFS should be implemented and how other servers implement PFS.
was (Author: bcall):
This is how PFS should be implemented and how other server implement PFS.
High CPU in 5.0
---
Key: TS-3016
URL: https://issues.apache.org/jira/browse/TS-3016
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Fix For: 5.1.0
After 5.0 roll out, our production systems are noticing much higher cpu
compared to pre-upgrade ats4 cpu usage.
For example, on some of our hosts running 8 hosts, below is the comparison
before and after the upgade:
{code}
cpu %util: 88.7% (version: ats5)
cpu %util: 70% (version: ats4)
{code}
Running perf top on traffic_server shows most CPU spent in SSL api calls,
initially causing us to suspect any SSL related changes. However, after some
analysis, it looks like the issue might be caused by the changes made in
TS-1365. After reverting the changes in TS-1365, the CPU usage comes back to
pre-upgrade levels again.
{code}
ats5:
--
Samples: 374K of event 'cycles', Event count (approx.): 29126701697
26.44% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
16.26% libcrypto.so.1.0.1e [.] bn_mul_mont --
6.74% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
4.95% libcrypto.so.1.0.1e [.] BN_usub
1.54% libcrypto.so.1.0.1e [.] sha256_block_data_order
1.37% libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery
80.89 libcrypto.so.1.0.1e
7.09 traffic_server
5.02 [kernel]
2.71 libc-2.12.so
0.59 libpthread-2.12.so
0.42 libssl.so.1.0.1e
0.32 libtsutil.so.5
0.32 [bnx2]
0.02 libstdc++.so.6.0.13
0.02 libpcre.so.0.0.1
0.01 quick_filter.so
0.01 libtcl8.5.so
0.01 librt-2.12.so
0.01 [kernel].vsyscall_fn
0.01 [kernel].vsyscall_1
0 regex_remap.so
0 libresolv-2.12.so
0 libgtlocip.so.1.7.4.B86
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [kernel].vsyscall_0
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
ats4:
-
Samples: 249K of event 'cycles', Event count (approx.): 18282595621
39.34% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
10.23% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
6.25% libcrypto.so.1.0.1e [.] bn_mul_mont --
2.19% libcrypto.so.1.0.1e [.] sha256_block_data_order
2.03% libcrypto.so.1.0.1e [.] BN_usub
1.50% [kernel] [k] find_busiest_group
1.08% libcrypto.so.1.0.1e [.] sha1_block_data_order_ssse3
80.93 libcrypto.so.1.0.1e
6.9 [kernel]
4.96 traffic_server
3 libc-2.12.so
0.84 libpthread-2.12.so
0.81 libssl.so.1.0.1e
0.38 [bnx2]
0.32 libtsutil.so.4
0.02 libtcl8.5.so
0.02 librt-2.12.so
0.02 libpcre.so.0.0.1
0.02 [kernel].vsyscall_fn
0.01 quick_filter.so
0.01 [kernel].vsyscall_1
0.01 [kernel].vsyscall_0
0 regex_remap.so
0 libstdc++.so.6.0.13
0 libresolv-2.12.so
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-3023) Support space separated values in inline plugin parameters in remap rules
Sudheer Vinukonda created TS-3023: - Summary: Support space separated values in inline plugin parameters in remap rules Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3023: -- Attachment: TS-3023.diff Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3023: -- Fix Version/s: (was: sometime) 5.2.0 Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3023: -- Fix Version/s: sometime Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[
https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102622#comment-14102622
]
Sudheer Vinukonda commented on TS-3023:
---
Sample test output for the below config:
map https://abc.com https://abc.com @plugin=conf_remap.so
@pparam=proxy.config.http.global_user_agent_header='ABC DEF'
@pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=ABC DEF
@pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
{code}
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Viewing all
parameters for config line
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 0:
plugin=conf_remap.so
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 1:
pparam=proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 2:
pparam=proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 3:
pparam=proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 4:
pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Viewing
parsed plugin parameters for /home/y/libexec64/trafficserver/conf_remap.so: [0]
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 0:
https://dev1.stg.uff.corp.gq1.yahoo.com/
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 1:
https://www.flickr.com/
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 2:
proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 3:
proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 4:
proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 5:
proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value 'ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
{code}
Support space separated values in inline plugin parameters in remap rules
-
Key: TS-3023
URL: https://issues.apache.org/jira/browse/TS-3023
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Fix For: 5.2.0
Attachments: TS-3023.diff
While reviewing and testing TS-2947, Leif found that, space separated values
are not supported correctly for inline plugin params whereas, they work as
expected when specified in the config file.
For example,
@pparam=proxy.config.foo='bar beer' results only in setting
proxy.config.foo=bar
whereas
CONFIG proxy.config.foo STRING 'bar beer' results in setting
proxy.config.foo='bar beer'
Further analysis revealed that the limitation is in parsing/tokenizing the
input, which always treats space or tab as delimiters, regardless of whether
they are included within quotes.
--
This message
[jira] [Comment Edited] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[
https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102622#comment-14102622
]
Sudheer Vinukonda edited comment on TS-3023 at 8/19/14 6:45 PM:
Sample test output (with the patch) for the below config:
map https://abc.com https://abc.com @plugin=conf_remap.so
@pparam=proxy.config.http.global_user_agent_header='ABC DEF'
@pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=ABC DEF
@pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
{code}
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Viewing all
parameters for config line
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 0:
plugin=conf_remap.so
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 1:
pparam=proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 2:
pparam=proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 3:
pparam=proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 4:
pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Viewing
parsed plugin parameters for /home/y/libexec64/trafficserver/conf_remap.so: [0]
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 0:
https://dev1.stg.uff.corp.gq1.yahoo.com/
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 1:
https://www.flickr.com/
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 2:
proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 3:
proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 4:
proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 5:
proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value 'ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header=ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value ABC DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) argv =
proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) parse_inline
argv = proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DIAG: (conf_remap) value ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
{code}
was (Author: sudheerv):
Sample test output for the below config:
map https://abc.com https://abc.com @plugin=conf_remap.so
@pparam=proxy.config.http.global_user_agent_header='ABC DEF'
@pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=ABC DEF
@pparam=proxy.config.http.global_user_agent_header=ABC
@pparam=proxy.config.http.global_user_agent_header=DEF
{code}
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Viewing all
parameters for config line
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 0:
plugin=conf_remap.so
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 1:
pparam=proxy.config.http.global_user_agent_header='ABC DEF'
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 2:
pparam=proxy.config.http.global_user_agent_header=ABC
[Aug 19 18:10:25.566] Server {0x2adaa78348e0} DEBUG: (url_rewrite) Argument 3:
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102703#comment-14102703
]
ASF subversion and git services commented on TS-2095:
-
Commit 57a48ee109d56e4c7bff249b369c8215de77b284 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=57a48ee ]
Revert TS-2095: autoconf warnings related to unordered_map
This reverts commit 957e60b917bd80ce9ae1de3fdc7e47afaa8cfc08.
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.1.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102714#comment-14102714
]
Leif Hedstrom commented on TS-2095:
---
The last commit seems to have broken builds in various ways. I found at least
two different failures:
{code}
checking for boostlib = 1.33... configure: We could not detect the boost
libraries (version 1.33 or higher). If you have a staged boost library (still
not installed) please specify $BOOST_ROOT in your environment and do not give a
PATH to --with-boost option. If you are sure you have boost installed, then
check your version number looking in boost/version.hpp. See
http://randspringer.de/boost for more documentation.
checking for library containing crypt... no
checking for pkg-config... /bin/pkg-config
checking whether compiling and linking against OpenSSL works... no
configure: error: failed to find OpenSSL
Build step 'Execute shell' marked build as failure
Warning: you have no plugins providing access control for builds, so falling
back to legacy behavior of permitting any downstream builds to be triggered
Finished: FAILURE
{code}
and
{code}
../../../../lib/ts/ink_inet.cc: In function 'hostent*
ink_gethostbyname_r(char*, ink_gethostbyname_r_data*)':
../../../../lib/ts/ink_inet.cc:61:52: error: cannot convert 'int*' to
'hostent**' for argument '5' to 'int gethostbyname_r(const char*, hostent*,
char*, size_t, hostent**, int*)'
data-herrno);
{code}
In addition, also saw at least one case with a regression failure, but that
might be different?
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.1.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reopened TS-2095:
---
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.1.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2902) Allow POST requests without a Content-Length header
[
https://issues.apache.org/jira/browse/TS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102746#comment-14102746
]
ASF subversion and git services commented on TS-2902:
-
Commit 10be14487652779e95dc9850b15cf28c095af0a0 in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=10be144 ]
TS-2902 Also add the new config to the regression tests
Allow POST requests without a Content-Length header
---
Key: TS-2902
URL: https://issues.apache.org/jira/browse/TS-2902
Project: Traffic Server
Issue Type: Improvement
Reporter: Masakazu Kitajo
Assignee: Bryan Call
Labels: review
Fix For: 5.1.0
Attachments: make_it_configuarable.patch
I get *400* Content Length Required when user agents send a POST request
that doesn't contain any body data without a Content-Length header.
(The header is omitted because the length is zero, I think)
According to RFC2730 Section 3.3.2, presence of Content-Length is not MUST.
http://tools.ietf.org/html/rfc7230#section-3.3.2
{quote}
A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body.
{quote}
Also according to section 3.3.3, a server are allowed to reject similar
request with 411 Length Required, but not *400*.
http://tools.ietf.org/html/rfc7230#section-3.3.2
{quote}
A server MAY reject a request that contains a message body but not a
Content-Length by responding with 411 (Length Required).
{quote}
Traffic Server should accept the requests, no body data without
Content-Length header, or reject it with *411*. I think the former one is
better for interoperability.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2947) Make the setting proxy.config.http.global_user_agent_header overrideable per remap
[ https://issues.apache.org/jira/browse/TS-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102745#comment-14102745 ] ASF subversion and git services commented on TS-2947: - Commit f37b13bd65f0a8dba0e9a2e11a3f615dc7e2df43 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f37b13b ] [TS-2947] Make the setting proxy.config.http.global_user_agent_header overrideable. Make the setting proxy.config.http.global_user_agent_header overrideable per remap -- Key: TS-2947 URL: https://issues.apache.org/jira/browse/TS-2947 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Leif Hedstrom Labels: review Fix For: 5.1.0 Attachments: TS-2947.diff There's a requirement among some of our origins to see custom and different user_agent headers. This ticket adds the setting proxy.config.http.global_user_agent_header to the list of overrideable params. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2968) CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable
[ https://issues.apache.org/jira/browse/TS-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2968: -- Fix Version/s: (was: 5.1.0) 5.2.0 CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable Key: TS-2968 URL: https://issues.apache.org/jira/browse/TS-2968 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: A Fix For: 5.2.0 Make this overridable per remap rule / plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2913) Could not process this request error when using redirect remap
[ https://issues.apache.org/jira/browse/TS-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102759#comment-14102759 ] Leif Hedstrom commented on TS-2913: --- Hmm, so I'm still seeing this with 5.1.0 RC... Could not process this request error when using redirect remap Key: TS-2913 URL: https://issues.apache.org/jira/browse/TS-2913 Project: Traffic Server Issue Type: Bug Components: Remap API Reporter: Ask Bjørn Hansen Assignee: Leif Hedstrom Fix For: 5.1.0 With this remap rule: redirect http://foo.example.com/ \ http://foo.example.com/path The server responds with a Location: header as expected, but also with an error template. (This is on 4.2.1-ish). HTML HEAD TITLEError/TITLE /HEAD BODY BGCOLOR=white FGCOLOR=black H1Error/H1 HR FONT FACE=Helvetica,ArialB Description: Could not process this request. /B/FONT HR /BODY -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102795#comment-14102795 ] James Peach commented on TS-3023: - Seems better to use the options flag than adding extra options. Could use some tests too. Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102804#comment-14102804 ] Sudheer Vinukonda commented on TS-3023: --- Ah, thanks [~jpe...@apache.org] - I agree that's a cleaner approach - will modify the patch to use options flag and will try to add some tests too. Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-3022) double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-3022:
---
Assignee: Alan M. Carroll
double free or corruption (!prev)
-
Key: TS-3022
URL: https://issues.apache.org/jira/browse/TS-3022
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: bettydramit
Assignee: Alan M. Carroll
Priority: Blocker
Fix For: 5.1.0
Centos 6 x86_64 gitmaster
Enable ocsp
config set
{code}
CONFIG proxy.config.ssl.ocsp.enabled INT 1
CONFIG proxy.config.ssl.ocsp.update_period INT 60
{code}
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x02af8be0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
/lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
/usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
/usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
/usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
/usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
/usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
/usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
/usr/bin/traffic_server[0x73eb5a]
/lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1547:
Fix Version/s: (was: 5.1.0)
5.2.0
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: William Bardwell
Labels: A, crash
Fix For: 5.2.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2095:
Fix Version/s: (was: 5.1.0)
5.2.0
autoconf warnings related to unordered_map
--
Key: TS-2095
URL: https://issues.apache.org/jira/browse/TS-2095
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Bryan Call
Fix For: 5.2.0
{code}
configure: WARNING: unordered_map: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_map: proceeding with the compiler's result
checking for unordered_map... yes
checking unordered_set usability... yes
checking unordered_set presence... no
configure: WARNING: unordered_set: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: unordered_set: proceeding with the compiler's result
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2153) traffic_manager -tsArgs without -M is fatal error
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2153:
Fix Version/s: (was: 5.1.0)
5.2.0
traffic_manager -tsArgs without -M is fatal error
-
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Assignee: Jack Bates
Fix For: 5.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 was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2574) Sharing server sessions per thread doesn't work when doing https to http
[ https://issues.apache.org/jira/browse/TS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2574. - Resolution: Fixed Sharing server sessions per thread doesn't work when doing https to http Key: TS-2574 URL: https://issues.apache.org/jira/browse/TS-2574 Project: Traffic Server Issue Type: Bug Components: HTTP, SSL Reporter: Bryan Call Assignee: Brian Geffon Fix For: 5.1.0 Attachments: TS-2574.patch When running a reverse proxy with incoming https scheme and outgoing http, the share server sessions value of 2 doesn't work. Since the https and http thread pools are separate after using the http connection it will be released to the http thread. When a new https request comes in it will look in the https threads servers session pool to make a request to the origin even though it is a http request. Of course it will fail the lookup since the ports wont match. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2490: Fix Version/s: (was: 5.1.0) 5.2.0 traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Assignee: James Peach Labels: review, yahoo Fix For: 5.2.0 Attachments: TS-2490.diff Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2279) proxy.config.exec_thread.affinity's values
[
https://issues.apache.org/jira/browse/TS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102864#comment-14102864
]
Leif Hedstrom commented on TS-2279:
---
As we discussed a few times, it feels that with the new life cycles in
traffic_server, some of this could move over there. Such as, traffic_server
knows when it's ready to serve requests (proxy), and maybe that should trigger
the start of external health checks and monitoring. A good question was brought
up, in that you don't want a life cycle to be allowed to take arbitrarily long
time, but that can probably be configured and managed in traffic_server itself,
such that it won't allow a certain life cycle to take too long.
Basically, simplify traffic_cop (maybe even eliminate all / most of it), in
favor of using Linux tools, and more intelligence in traffic_server itself.
proxy.config.exec_thread.affinity's values
--
Key: TS-2279
URL: https://issues.apache.org/jira/browse/TS-2279
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.1.0
The setting of {{proxy.config.exec_thread.affinity}} only has an affect when
traffic server was compiled with {{\-\-enable-hwloc}}. It has *no* affect at
all, not even a warning about its being ineffectual when setting that value
while trafficserver is *not* configured with {{--enable-hwloc}}.
Further, mgmt/RecordsConfig.cc defines a range of {{[0-1]}}:
{code}
{RECT_CONFIG, proxy.config.exec_thread.affinity, RECD_INT, 0,
RECU_RESTART_TS, RR_NULL, RECC_INT, [0-1], RECA_READ_ONLY}
{code}
but the code uses a range of [0-3]:
{code}
#if TS_USE_HWLOC
if (affinity != 0) {
int logical_ratio;
switch(affinity) {
case 3: // assign threads to logical cores
logical_ratio = 1;
break;
case 2: // assign threads to real cores
logical_ratio = pu / cu;
break;
case 1: // assign threads to sockets
default:
logical_ratio = pu / socket;
}
{code}
And finally, 1 is the default value, rather than issuing a warning about an
incorrect value.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102866#comment-14102866 ] Leif Hedstrom commented on TS-2490: --- As we discussed a few times, it feels that with the new life cycles in traffic_server, some of this could move over there. Such as, traffic_server knows when it's ready to serve requests (proxy), and maybe that should trigger the start of external health checks and monitoring. A good question was brought up, in that you don't want a life cycle to be allowed to take arbitrarily long time, but that can probably be configured and managed in traffic_server itself, such that it won't allow a certain life cycle to take too long. Basically, simplify traffic_cop (maybe even eliminate all / most of it), in favor of using Linux tools, and more intelligence in traffic_server itself traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Assignee: James Peach Labels: review, yahoo Fix For: 5.2.0 Attachments: TS-2490.diff Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102869#comment-14102869 ] Brian Geffon commented on TS-2905: -- Can you provide more information, it's not clear how this could happen with a TCP_HIT. This error should only happen if the sockaddr isn't an ipv4 or ivp6 address. Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.2.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2905: Fix Version/s: (was: 5.1.0) 5.2.0 Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.2.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (TS-2279) proxy.config.exec_thread.affinity's values
[
https://issues.apache.org/jira/browse/TS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2279:
--
Comment: was deleted
(was: As we discussed a few times, it feels that with the new life cycles in
traffic_server, some of this could move over there. Such as, traffic_server
knows when it's ready to serve requests (proxy), and maybe that should trigger
the start of external health checks and monitoring. A good question was brought
up, in that you don't want a life cycle to be allowed to take arbitrarily long
time, but that can probably be configured and managed in traffic_server itself,
such that it won't allow a certain life cycle to take too long.
Basically, simplify traffic_cop (maybe even eliminate all / most of it), in
favor of using Linux tools, and more intelligence in traffic_server itself.)
proxy.config.exec_thread.affinity's values
--
Key: TS-2279
URL: https://issues.apache.org/jira/browse/TS-2279
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.1.0
The setting of {{proxy.config.exec_thread.affinity}} only has an affect when
traffic server was compiled with {{\-\-enable-hwloc}}. It has *no* affect at
all, not even a warning about its being ineffectual when setting that value
while trafficserver is *not* configured with {{--enable-hwloc}}.
Further, mgmt/RecordsConfig.cc defines a range of {{[0-1]}}:
{code}
{RECT_CONFIG, proxy.config.exec_thread.affinity, RECD_INT, 0,
RECU_RESTART_TS, RR_NULL, RECC_INT, [0-1], RECA_READ_ONLY}
{code}
but the code uses a range of [0-3]:
{code}
#if TS_USE_HWLOC
if (affinity != 0) {
int logical_ratio;
switch(affinity) {
case 3: // assign threads to logical cores
logical_ratio = 1;
break;
case 2: // assign threads to real cores
logical_ratio = pu / cu;
break;
case 1: // assign threads to sockets
default:
logical_ratio = pu / socket;
}
{code}
And finally, 1 is the default value, rather than issuing a warning about an
incorrect value.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2926) IP Clearance for ats_speed - PageSpeed Optimization plugin
[ https://issues.apache.org/jira/browse/TS-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2926. - Resolution: Fixed IP Clearance for ats_speed - PageSpeed Optimization plugin -- Key: TS-2926 URL: https://issues.apache.org/jira/browse/TS-2926 Project: Traffic Server Issue Type: Task Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Attachments: ats_speed-master.zip Ats_speed is a plugin by We-Amp which enables easy and automatic web performance optimization powered by Google's PageSpeed optimization SDK (like mod_pagespeed). The donated code currently lives at https://github.com/We-Amp/ats_speed Also, See http://www.atsspeed.com/ for more information. Since this code was developed outside of the Apache process it is required to go through the IP Clearance procedure which is managed by the Incubator - https://incubator.apache.org/ip-clearance/index.html This issue will act as a tracking point for tasks related to carrying out the IP Clearance process: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/ats-ats_speed.xml -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2938) Core dump in HttpSM::redirect_request when handling 307
[
https://issues.apache.org/jira/browse/TS-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2938:
Fix Version/s: (was: 5.1.0)
5.2.0
Core dump in HttpSM::redirect_request when handling 307
---
Key: TS-2938
URL: https://issues.apache.org/jira/browse/TS-2938
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Assignee: James Peach
Labels: yahoo
Fix For: 5.2.0
Attachments: TS-2938.diff
Below is the gdb back trace and other info. Looks like
t_state.hdr_info.server_request is not valid when handling 307.
{code}
#0 method_get (this=0x2b294c6c4dd0,
redirect_url=0x2b2a1ff0d914
http://ads.unister-gmbh.de/newsletter_img/aidude/template/countdown/hfr/countdown180.gif\r\nCache-Control:
max-age=600, public, must-revalidate\r\nVary:
Accept-Encoding\r\nContent-Encoding: gzip\r\nContent-Ty...,
redirect_len=value optimized out) at ../../proxy/hdrs/HTTP.h:1031
#1 HttpSM::redirect_request (this=0x2b294c6c4dd0,
redirect_url=0x2b2a1ff0d914
http://ads.unister-gmbh.de/newsletter_img/aidude/template/countdown/hfr/countdown180.gif\r\nCache-Control:
max-age=600, public, must-revalidate\r\nVary:
Accept-Encoding\r\nContent-Encoding: gzip\r\nContent-Ty...,
redirect_len=value optimized out) at HttpSM.cc:7416
#2 0x00599dcb in HttpSM::do_redirect (this=0x2b294c6c4dd0) at
HttpSM.cc:7350
#3 0x005aa968 in HttpSM::set_next_state (this=0x2b294c6c4dd0) at
HttpSM.cc:7050
#4 0x005ac462 in HttpSM::handle_api_return (this=0x2b294c6c4dd0) at
HttpSM.cc:1505
#5 0x005a48e0 in HttpSM::state_api_callout (this=0x2b294c6c4dd0,
event=0, data=0x0) at HttpSM.cc:1437
#6 0x005aa302 in HttpSM::set_next_state (this=0x2b294c6c4dd0) at
HttpSM.cc:6830
#7 0x005ac462 in HttpSM::handle_api_return (this=0x2b294c6c4dd0) at
HttpSM.cc:1505
#8 0x005a48e0 in HttpSM::state_api_callout (this=0x2b294c6c4dd0,
event=0, data=0x0) at HttpSM.cc:1437
#9 0x005aa302 in HttpSM::set_next_state (this=0x2b294c6c4dd0) at
HttpSM.cc:6830
#10 0x005ac462 in HttpSM::handle_api_return (this=0x2b294c6c4dd0) at
HttpSM.cc:1505
#11 0x005a48e0 in HttpSM::state_api_callout (this=0x2b294c6c4dd0,
event=0, data=0x0) at HttpSM.cc:1437
#12 0x005a7710 in do_api_callout (this=0x2b294c6c4dd0, event=value
optimized out, data=0xb050) at HttpSM.cc:444
#13 setup_cache_lookup_complete_api (this=0x2b294c6c4dd0, event=value
optimized out, data=0xb050) at HttpSM.cc:2403
#14 HttpSM::state_cache_open_read (this=0x2b294c6c4dd0, event=value
optimized out, data=0xb050) at HttpSM.cc:2459
#15 0x005a7418 in HttpSM::main_handler (this=0x2b294c6c4dd0,
event=1103, data=0xb050) at HttpSM.cc:2501
#16 0x00585882 in handleEvent (this=0x2b294c6c67a0, event=1103,
data=0xb050) at ../../iocore/eventsystem/I_Continuation.h:146
#17 HttpCacheSM::state_cache_open_read (this=0x2b294c6c67a0, event=1103,
data=0xb050) at HttpCacheSM.cc:137
#18 0x006dbf5e in Cache::open_read (this=value optimized out,
cont=0x2b294c6c67a0, key=value optimized out, request=0x2b294c6c54d8,
params=0x2b294c6c4eb0,
type=value optimized out,
hostname=0x2b2977c3aaeb
ads.unister-gmbh.denewsletter_img/aidude/template/countdown/hfr/countdown180.gifhttpads.unister-gmbh.denewsletter_img/aidude/template/countdown/hfr/countdown180.gifhttpads.unister-gmbh.denewsletter_im...,
host_len=19) at CacheRead.cc:143
#19 0x006bcb9d in open_read (this=value optimized out,
cont=0x2b294c6c67a0, url=0x2b294c6c54f0, cluster_cache_local=value optimized
out, request=0x2b294c6c54d8,
params=0x2b294c6c4eb0, pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at
P_CacheInternal.h:1079
#20 CacheProcessor::open_read (this=value optimized out,
cont=0x2b294c6c67a0, url=0x2b294c6c54f0, cluster_cache_local=value optimized
out, request=0x2b294c6c54d8, params=0x2b294c6c4eb0,
pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3440
#21 0x00585334 in do_cache_open_read (this=0x2b294c6c67a0, url=value
optimized out, hdr=value optimized out, params=value optimized out,
pin_in_cache=value optimized out)
at HttpCacheSM.cc:216
#22 HttpCacheSM::open_read (this=0x2b294c6c67a0, url=value optimized out,
hdr=value optimized out, params=value optimized out, pin_in_cache=value
optimized out) at HttpCacheSM.cc:248
#23 0x005935e3 in HttpSM::do_cache_lookup_and_read
(this=0x2b294c6c4dd0) at HttpSM.cc:4279
#24 0x005aa824 in HttpSM::set_next_state (this=0x2b294c6c4dd0) at
HttpSM.cc:6943
#25 0x005ac59d in
[jira] [Updated] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2967:
Fix Version/s: (was: 5.1.0)
5.2.0
failed assert if ssl_multicert.config doesn't exist
---
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.2.0
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2945) balancer plugin forward to other port than 80
[ https://issues.apache.org/jira/browse/TS-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2945: Fix Version/s: (was: 5.1.0) 5.2.0 balancer plugin forward to other port than 80 - Key: TS-2945 URL: https://issues.apache.org/jira/browse/TS-2945 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Thibault Marquand Assignee: James Peach Fix For: 5.2.0 The balancer plugin can't load-balance on others ports than 80. In documentation of the plugin, there is nothing about how to load-balance on others ports. Syntax in remap.config : map http://foo.com http://foo.com @plugin=balancer.so @pparam=--policy=hash,url @pparam=one.bar.com @pparam=two.bar.com I obviously try this : map http://foo.com http://foo.com @plugin=balancer.so @pparam=--policy=hash,url @pparam=one.bar.com:8080 @pparam=two.bar.com:8080 But ATS continues to hit on port 80 on my web server and in error.log I get this : status 502 (Connect Error Connection refused/111) for 'http://two.bar.com:8080/' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2982) build error from gitmaster
[ https://issues.apache.org/jira/browse/TS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2982: --- Assignee: Alan M. Carroll (was: Phil Sorber) build error from gitmaster -- Key: TS-2982 URL: https://issues.apache.org/jira/browse/TS-2982 Project: Traffic Server Issue Type: Bug Reporter: bettydramit Assignee: Alan M. Carroll Fix For: 5.1.0 git master In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from MultiCache.cc:33: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from HostDB.cc:26: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' make[2]: *** [MultiCache.o] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3023: -- Attachment: TS-3023.diff Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3023: -- Attachment: (was: TS-3023.diff) Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2988) ats_speed: bail out when gurl-IsWebValid() != true
[
https://issues.apache.org/jira/browse/TS-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2988:
Fix Version/s: (was: 5.1.0)
5.2.0
ats_speed: bail out when gurl-IsWebValid() != true
---
Key: TS-2988
URL: https://issues.apache.org/jira/browse/TS-2988
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Otto van der Schaaf
Assignee: Otto van der Schaaf
Fix For: 5.2.0
Reported via https://github.com/We-Amp/ats_speed/issues/12
Prevent a CHECK failure by bailing out on urls that apparently can't be
parsed as web valid. Preferrably should emit a warning about it as well, as
it might be interesting to see which urls would fail.
[Aug 2 19:24:21.165] Server {0x7fc5b9a05700} DIAG: (ats-speed-vlog)
[1.7.30.4-3847] [0802/192421:FATAL:ats_speed.cc(719)] Check failed:
ctx-gurl-IsWebValid(). Invalid URL!
Backtrace:
/usr/libexec/trafficserver/ats_speed.so(+0x88f8a) [0x7fc5b6e26f8a]
/usr/libexec/trafficserver/ats_speed.so(+0x7b9d0) [0x7fc5b6e199d0]
/usr/libexec/trafficserver/ats_speed.so(+0x85fc9) [0x7fc5b6e23fc9]
/usr/libexec/trafficserver/ats_speed.so(handle_read_request_header(tsapi_httptxn*)+0x49d)
[0x7fc5b6e209cd]
/usr/libexec/trafficserver/ats_speed.so(+0x83218) [0x7fc5b6e21218]
traffic_server(HttpSM::state_api_callout(int, void*)+0x102) [0x5abee2]
traffic_server(HttpSM::state_api_callback(int, void*)+0x82) [0x5b0c22]
traffic_server(TSHttpTxnReenable+0x244) [0x4c8494]
/usr/libexec/trafficserver/gzip.so(+0x742b) [0x7fc5b765842b]
traffic_server(HttpSM::state_api_callout(int, void*)+0x102) [0x5abee2]
traffic_server(HttpSM::set_next_state()+0x1db) [0x5b0efb]
traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x38f) [0x5a4c9f]
traffic_server(HttpSM::main_handler(int, void*)+0xbd) [0x5b0a3d]
traffic_server(HttpSM::state_api_callout(int, void*)+0x2c0) [0x5ac0a0]
traffic_server(HttpSM::state_add_to_list(int, void*)+0x190) [0x5aca10]
traffic_server(HttpSM::attach_client_session(HttpClientSession*,
IOBufferReader*)+0x38a) [0x5b089a]
traffic_server(HttpClientSession::new_transaction()+0x9f) [0x58f54f]
traffic_server(HttpClientSession::state_api_callout(int, void*)+0x1cf)
[0x59086f]
traffic_server(HttpClientSession::new_connection(NetVConnection*, bool,
MIOBuffer*, IOBufferReader*)+0x4d9) [0x5914c9]
traffic_server(HttpSessionAccept::accept(NetVConnection*, MIOBuffer*,
IOBufferReader*)+0x203) [0x58bbd3]
traffic_server(ProtocolProbeTrampoline::ioCompletionEvent(int,
void*)+0x3c8) [0x4eb968]
traffic_server() [0x715ebb]
traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2) [0x709122]
traffic_server(EThread::execute()+0xad3) [0x737e93]
traffic_server() [0x7368ca]
/lib64/libpthread.so.0(+0x7f18) [0x7fc5bd15ff18]
/lib64/libc.so.6(clone+0x6d) [0x7fc5bc112e9d]
Aborted
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3004) Correct Vendor name in Page Speed Plugin
[ https://issues.apache.org/jira/browse/TS-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3004: -- Component/s: Plugins Correct Vendor name in Page Speed Plugin Key: TS-3004 URL: https://issues.apache.org/jira/browse/TS-3004 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Christian Grobmeier Assignee: Otto van der Schaaf Fix For: 5.1.0 As PageSpeed is part of the ASF now, vendor name and support email should be corrected, or removed. https://github.com/apache/trafficserver/blob/8b1467e4941ce6f9e781bfafbec229c983be032a/plugins/experimental/ats_speed/ats_speed.cc#L970-L971 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3003) Remove overwriting of robots.txt in page speed plugin
[ https://issues.apache.org/jira/browse/TS-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3003: -- Component/s: Plugins Remove overwriting of robots.txt in page speed plugin - Key: TS-3003 URL: https://issues.apache.org/jira/browse/TS-3003 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Christian Grobmeier Assignee: Otto van der Schaaf Fix For: 5.2.0 Currently the page speed plugin overwrites /robots.txt with its own content. This leads to problems in our setup, as Google cannot index our cached website. The following lines: https://github.com/apache/trafficserver/blob/master/plugins/experimental/ats_speed/ats_resource_intercept.cc#L281-L286 demonstrate how page speed subdues our own robots.txt and overwrites it with own content for unknown reasons. Also the second if/else can be removed as it currently has no further use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-3004) Correct Vendor name in Page Speed Plugin
[ https://issues.apache.org/jira/browse/TS-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-3004: --- Assignee: Phil Sorber (was: Otto van der Schaaf) Correct Vendor name in Page Speed Plugin Key: TS-3004 URL: https://issues.apache.org/jira/browse/TS-3004 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Christian Grobmeier Assignee: Phil Sorber Fix For: 5.1.0 As PageSpeed is part of the ASF now, vendor name and support email should be corrected, or removed. https://github.com/apache/trafficserver/blob/8b1467e4941ce6f9e781bfafbec229c983be032a/plugins/experimental/ats_speed/ats_speed.cc#L970-L971 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3003) Remove overwriting of robots.txt in page speed plugin
[ https://issues.apache.org/jira/browse/TS-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-3003: Fix Version/s: (was: 5.1.0) 5.2.0 Remove overwriting of robots.txt in page speed plugin - Key: TS-3003 URL: https://issues.apache.org/jira/browse/TS-3003 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Christian Grobmeier Assignee: Otto van der Schaaf Fix For: 5.2.0 Currently the page speed plugin overwrites /robots.txt with its own content. This leads to problems in our setup, as Google cannot index our cached website. The following lines: https://github.com/apache/trafficserver/blob/master/plugins/experimental/ats_speed/ats_resource_intercept.cc#L281-L286 demonstrate how page speed subdues our own robots.txt and overwrites it with own content for unknown reasons. Also the second if/else can be removed as it currently has no further use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-3018) Client Request's default port can't be changed after scheme was changed
[
https://issues.apache.org/jira/browse/TS-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-3018.
-
Resolution: Fixed
We consider this a duplicate of TS-2933.
Client Request's default port can't be changed after scheme was changed
---
Key: TS-3018
URL: https://issues.apache.org/jira/browse/TS-3018
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: kang li
Assignee: Alan M. Carroll
Fix For: 5.1.0
If I received a client request with scheme http and there are no port set in
Host header or absolute URI in http request. Then I change the scheme to
https. But when in url remap, it still get the port as 80 which indicated by
the previous scheme.
{code}
1475 } else if (0 != (m_host_mime =
const_castHTTPHdr*(this)-get_host_port_values(0, m_host_length,
port_ptr, 0))) {
1476 if (port_ptr) {
1477 m_port = 0;
1478 for ( ; is_digit(*port_ptr) ; ++port_ptr )
1479 m_port = m_port * 10 + *port_ptr - '0';
1480 m_port_in_header = (0 != m_port);
1481 }
1482 m_port = url_canonicalize_port(url-m_url_impl-m_url_type, m_port);
{code}
That seems the m_port was not reset to 0 when it second time try to get the
port by url type (which was reset in UrlSchemeSet). So it always get the port
in the initial time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102896#comment-14102896 ] Phil Sorber commented on TS-3005: - What about just pagespeed or page_speed? The ats_ seems redundant. Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3022:
--
Summary: OCSP double free or corruption (!prev) (was: double free or
corruption (!prev))
OCSP double free or corruption (!prev)
--
Key: TS-3022
URL: https://issues.apache.org/jira/browse/TS-3022
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: bettydramit
Assignee: Alan M. Carroll
Priority: Blocker
Fix For: 5.1.0
Centos 6 x86_64 gitmaster
Enable ocsp
config set
{code}
CONFIG proxy.config.ssl.ocsp.enabled INT 1
CONFIG proxy.config.ssl.ocsp.update_period INT 60
{code}
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x02af8be0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
/lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
/usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
/usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
/usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
/usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
/usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
/usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
/usr/bin/traffic_server[0x73eb5a]
/lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102905#comment-14102905 ] Otto van der Schaaf commented on TS-3005: - Please wait with this one. I've been working on an upgrade to the latest pagespeed SDK plus the new in-place flow at https://github.com/apache/trafficserver/tree/oschaaf-ipro-flow I fair that renaming all these things could make things very-hard to merge, as it's not a minor change. Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102905#comment-14102905 ] Otto van der Schaaf edited comment on TS-3005 at 8/19/14 9:46 PM: -- Please wait with this one. I've been working on an upgrade to the latest pagespeed SDK plus the new in-place flow at https://github.com/apache/trafficserver/tree/oschaaf-ipro-flow I fear that renaming all these things could make things very-hard to merge, as it's not a minor change. was (Author: oschaaf): Please wait with this one. I've been working on an upgrade to the latest pagespeed SDK plus the new in-place flow at https://github.com/apache/trafficserver/tree/oschaaf-ipro-flow I fair that renaming all these things could make things very-hard to merge, as it's not a minor change. Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-3004) Correct Vendor name in Page Speed Plugin
[ https://issues.apache.org/jira/browse/TS-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-3004. - Resolution: Done Correct Vendor name in Page Speed Plugin Key: TS-3004 URL: https://issues.apache.org/jira/browse/TS-3004 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Christian Grobmeier Assignee: Phil Sorber Fix For: 5.1.0 As PageSpeed is part of the ASF now, vendor name and support email should be corrected, or removed. https://github.com/apache/trafficserver/blob/8b1467e4941ce6f9e781bfafbec229c983be032a/plugins/experimental/ats_speed/ats_speed.cc#L970-L971 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3004) Correct Vendor name in Page Speed Plugin
[ https://issues.apache.org/jira/browse/TS-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102910#comment-14102910 ] ASF subversion and git services commented on TS-3004: - Commit fff07bcf6e957ed8ac442d5f6001d3085cb9bba6 in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fff07bc ] TS-3004: Update vendor_name and support_email in ats_speed plugin Correct Vendor name in Page Speed Plugin Key: TS-3004 URL: https://issues.apache.org/jira/browse/TS-3004 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Christian Grobmeier Assignee: Phil Sorber Fix For: 5.1.0 As PageSpeed is part of the ASF now, vendor name and support email should be corrected, or removed. https://github.com/apache/trafficserver/blob/8b1467e4941ce6f9e781bfafbec229c983be032a/plugins/experimental/ats_speed/ats_speed.cc#L970-L971 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-2983:
---
Assignee: Alan M. Carroll
request headers, http object corrupted in 5.0.x
---
Key: TS-2983
URL: https://issues.apache.org/jira/browse/TS-2983
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 5.1.0
Reporter: Sudheer Vinukonda
Assignee: Alan M. Carroll
Priority: Blocker
Fix For: 5.1.0
We have run into a http header/field corruption issue on our proxy
infrastructure production hosts when we enabled 5.0.x. The issue results in
host header/method and other field corruption.
For example, this is what we see in our squid access logs:
{code}
1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0disclaimer=2;
https://AMCV_att1=x;%20ypcdb=xx - NONE/- -
{code}
After a lot of debugging, figured that the request was getting corrupted even
before remap and in fact, is being parsed incorrectly at the read request
state. Further analysis lead me to the commit TS-2197 (commit
30fcc2b2e698831d1a9e4db1474d8cfc202818a3 in Oct'13), which has altered the
way the request is read slightly. Reverting the commit seems to have fixed
the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3022) OCSP double free or corruption (!prev)
[
https://issues.apache.org/jira/browse/TS-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3022:
Assignee: James Peach (was: Alan M. Carroll)
OCSP double free or corruption (!prev)
--
Key: TS-3022
URL: https://issues.apache.org/jira/browse/TS-3022
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: bettydramit
Assignee: James Peach
Priority: Blocker
Fix For: 5.1.0
Centos 6 x86_64 gitmaster
Enable ocsp
config set
{code}
CONFIG proxy.config.ssl.ocsp.enabled INT 1
CONFIG proxy.config.ssl.ocsp.update_period INT 60
{code}
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(!prev): 0x02af8be0 ***
=== Backtrace: =
/lib64/libc.so.6(+0x76166)[0x2ac6c2294166]
/lib64/libc.so.6(+0x78c93)[0x2ac6c2296c93]
/usr/lib64/libcrypto.so.10(CRYPTO_free+0x1d)[0x2ac6bfb990ad]
/usr/lib64/libcrypto.so.10(+0x68ada)[0x2ac6bfb9aada]
/usr/lib64/libssl.so.10(SSL_CTX_free+0x6e)[0x2ac6bf907e7e]
/usr/bin/traffic_server(_ZN17SSLContextStorageD1Ev+0x59)[0x72c489]
/usr/bin/traffic_server(_ZN13SSLCertLookupD0Ev+0x29)[0x72c5f9]
/usr/bin/traffic_server(_ZN18ConfigInfoReleaser12handle_eventEiPv+0x17)[0x665da7]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73f7bf]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5c3)[0x740173]
/usr/bin/traffic_server[0x73eb5a]
/lib64/libpthread.so.0(+0x79d1)[0x2ac6c13109d1]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2988) ats_speed: bail out when gurl-IsWebValid() != true
[
https://issues.apache.org/jira/browse/TS-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102931#comment-14102931
]
Otto van der Schaaf commented on TS-2988:
-
This is already fixed. Where can I find the workflow for jira issues and the
release process? Should be marked fix-version 5.1.0?
ats_speed: bail out when gurl-IsWebValid() != true
---
Key: TS-2988
URL: https://issues.apache.org/jira/browse/TS-2988
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Otto van der Schaaf
Assignee: Otto van der Schaaf
Fix For: 5.2.0
Reported via https://github.com/We-Amp/ats_speed/issues/12
Prevent a CHECK failure by bailing out on urls that apparently can't be
parsed as web valid. Preferrably should emit a warning about it as well, as
it might be interesting to see which urls would fail.
[Aug 2 19:24:21.165] Server {0x7fc5b9a05700} DIAG: (ats-speed-vlog)
[1.7.30.4-3847] [0802/192421:FATAL:ats_speed.cc(719)] Check failed:
ctx-gurl-IsWebValid(). Invalid URL!
Backtrace:
/usr/libexec/trafficserver/ats_speed.so(+0x88f8a) [0x7fc5b6e26f8a]
/usr/libexec/trafficserver/ats_speed.so(+0x7b9d0) [0x7fc5b6e199d0]
/usr/libexec/trafficserver/ats_speed.so(+0x85fc9) [0x7fc5b6e23fc9]
/usr/libexec/trafficserver/ats_speed.so(handle_read_request_header(tsapi_httptxn*)+0x49d)
[0x7fc5b6e209cd]
/usr/libexec/trafficserver/ats_speed.so(+0x83218) [0x7fc5b6e21218]
traffic_server(HttpSM::state_api_callout(int, void*)+0x102) [0x5abee2]
traffic_server(HttpSM::state_api_callback(int, void*)+0x82) [0x5b0c22]
traffic_server(TSHttpTxnReenable+0x244) [0x4c8494]
/usr/libexec/trafficserver/gzip.so(+0x742b) [0x7fc5b765842b]
traffic_server(HttpSM::state_api_callout(int, void*)+0x102) [0x5abee2]
traffic_server(HttpSM::set_next_state()+0x1db) [0x5b0efb]
traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x38f) [0x5a4c9f]
traffic_server(HttpSM::main_handler(int, void*)+0xbd) [0x5b0a3d]
traffic_server(HttpSM::state_api_callout(int, void*)+0x2c0) [0x5ac0a0]
traffic_server(HttpSM::state_add_to_list(int, void*)+0x190) [0x5aca10]
traffic_server(HttpSM::attach_client_session(HttpClientSession*,
IOBufferReader*)+0x38a) [0x5b089a]
traffic_server(HttpClientSession::new_transaction()+0x9f) [0x58f54f]
traffic_server(HttpClientSession::state_api_callout(int, void*)+0x1cf)
[0x59086f]
traffic_server(HttpClientSession::new_connection(NetVConnection*, bool,
MIOBuffer*, IOBufferReader*)+0x4d9) [0x5914c9]
traffic_server(HttpSessionAccept::accept(NetVConnection*, MIOBuffer*,
IOBufferReader*)+0x203) [0x58bbd3]
traffic_server(ProtocolProbeTrampoline::ioCompletionEvent(int,
void*)+0x3c8) [0x4eb968]
traffic_server() [0x715ebb]
traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2) [0x709122]
traffic_server(EThread::execute()+0xad3) [0x737e93]
traffic_server() [0x7368ca]
/lib64/libpthread.so.0(+0x7f18) [0x7fc5bd15ff18]
/lib64/libc.so.6(clone+0x6d) [0x7fc5bc112e9d]
Aborted
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2279) proxy.config.exec_thread.affinity's values
[
https://issues.apache.org/jira/browse/TS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102940#comment-14102940
]
ASF subversion and git services commented on TS-2279:
-
Commit 29f6b959c5fa9eb8b5f0340ed7b91fc33d326582 in trafficserver's branch
refs/heads/master from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=29f6b95 ]
TS-2279: Update range for proxy.config.exec_thread.affinity
proxy.config.exec_thread.affinity's values
--
Key: TS-2279
URL: https://issues.apache.org/jira/browse/TS-2279
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.1.0
The setting of {{proxy.config.exec_thread.affinity}} only has an affect when
traffic server was compiled with {{\-\-enable-hwloc}}. It has *no* affect at
all, not even a warning about its being ineffectual when setting that value
while trafficserver is *not* configured with {{--enable-hwloc}}.
Further, mgmt/RecordsConfig.cc defines a range of {{[0-1]}}:
{code}
{RECT_CONFIG, proxy.config.exec_thread.affinity, RECD_INT, 0,
RECU_RESTART_TS, RR_NULL, RECC_INT, [0-1], RECA_READ_ONLY}
{code}
but the code uses a range of [0-3]:
{code}
#if TS_USE_HWLOC
if (affinity != 0) {
int logical_ratio;
switch(affinity) {
case 3: // assign threads to logical cores
logical_ratio = 1;
break;
case 2: // assign threads to real cores
logical_ratio = pu / cu;
break;
case 1: // assign threads to sockets
default:
logical_ratio = pu / socket;
}
{code}
And finally, 1 is the default value, rather than issuing a warning about an
incorrect value.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2279) proxy.config.exec_thread.affinity's values
[
https://issues.apache.org/jira/browse/TS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber resolved TS-2279.
-
Resolution: Fixed
Separate from this ticket, I had reworked this code. That is why the docs
differ between versions. The code quoted has all been reworked and the only
part still broken here was the range (that is not enforced as far as I know)
and is fixed now.
proxy.config.exec_thread.affinity's values
--
Key: TS-2279
URL: https://issues.apache.org/jira/browse/TS-2279
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.1.0
The setting of {{proxy.config.exec_thread.affinity}} only has an affect when
traffic server was compiled with {{\-\-enable-hwloc}}. It has *no* affect at
all, not even a warning about its being ineffectual when setting that value
while trafficserver is *not* configured with {{--enable-hwloc}}.
Further, mgmt/RecordsConfig.cc defines a range of {{[0-1]}}:
{code}
{RECT_CONFIG, proxy.config.exec_thread.affinity, RECD_INT, 0,
RECU_RESTART_TS, RR_NULL, RECC_INT, [0-1], RECA_READ_ONLY}
{code}
but the code uses a range of [0-3]:
{code}
#if TS_USE_HWLOC
if (affinity != 0) {
int logical_ratio;
switch(affinity) {
case 3: // assign threads to logical cores
logical_ratio = 1;
break;
case 2: // assign threads to real cores
logical_ratio = pu / cu;
break;
case 1: // assign threads to sockets
default:
logical_ratio = pu / socket;
}
{code}
And finally, 1 is the default value, rather than issuing a warning about an
incorrect value.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-3024) build with OPENSSL_NO_SSL_INTERN
James Peach created TS-3024:
---
Summary: build with OPENSSL_NO_SSL_INTERN
Key: TS-3024
URL: https://issues.apache.org/jira/browse/TS-3024
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: James Peach
I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3024) build with OPENSSL_NO_SSL_INTERN
[
https://issues.apache.org/jira/browse/TS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3024:
Assignee: Susan Hinrichs
build with OPENSSL_NO_SSL_INTERN
Key: TS-3024
URL: https://issues.apache.org/jira/browse/TS-3024
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: James Peach
Assignee: Susan Hinrichs
I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102969#comment-14102969 ] Phil Sorber commented on TS-3005: - The concern is a rename in a stable version. Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3024) build with OPENSSL_NO_SSL_INTERN
[
https://issues.apache.org/jira/browse/TS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3024:
Component/s: Build
build with OPENSSL_NO_SSL_INTERN
Key: TS-3024
URL: https://issues.apache.org/jira/browse/TS-3024
Project: Traffic Server
Issue Type: Bug
Components: Build, SSL
Reporter: James Peach
Assignee: Susan Hinrichs
I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2913) Could not process this request error when using redirect remap
[ https://issues.apache.org/jira/browse/TS-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103012#comment-14103012 ] ASF subversion and git services commented on TS-2913: - Commit 261b19ee347e0807ddce57684203f1de22e4b395 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=261b19e ] TS-2913 Missing body factory template for permanent redirects. Could not process this request error when using redirect remap Key: TS-2913 URL: https://issues.apache.org/jira/browse/TS-2913 Project: Traffic Server Issue Type: Bug Components: Remap API Reporter: Ask Bjørn Hansen Assignee: Leif Hedstrom Fix For: 5.1.0 With this remap rule: redirect http://foo.example.com/ \ http://foo.example.com/path The server responds with a Location: header as expected, but also with an error template. (This is on 4.2.1-ish). HTML HEAD TITLEError/TITLE /HEAD BODY BGCOLOR=white FGCOLOR=black H1Error/H1 HR FONT FACE=Helvetica,ArialB Description: Could not process this request. /B/FONT HR /BODY -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2913) Could not process this request error when using redirect remap
[ https://issues.apache.org/jira/browse/TS-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2913. --- Resolution: Fixed The problem is that we're not installing the permanent redirect body factory template :). [~ask] When you roll this internally, remember to update your packages such that you get this new file as well. Also, for upstream packagers, we should make sure your .spec / .deb files includes this missing factory file: etc/trafficserver/body_factory/default/redirect#moved_permanently Could not process this request error when using redirect remap Key: TS-2913 URL: https://issues.apache.org/jira/browse/TS-2913 Project: Traffic Server Issue Type: Bug Components: Remap API Reporter: Ask Bjørn Hansen Assignee: Leif Hedstrom Fix For: 5.1.0 With this remap rule: redirect http://foo.example.com/ \ http://foo.example.com/path The server responds with a Location: header as expected, but also with an error template. (This is on 4.2.1-ish). HTML HEAD TITLEError/TITLE /HEAD BODY BGCOLOR=white FGCOLOR=black H1Error/H1 HR FONT FACE=Helvetica,ArialB Description: Could not process this request. /B/FONT HR /BODY -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3024) build with OPENSSL_NO_SSL_INTERN
[
https://issues.apache.org/jira/browse/TS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103066#comment-14103066
]
Alan M. Carroll commented on TS-3024:
-
In general this seems reasonable but there will be some cases where it is
necessary to reach in to SSL data structures. For instance, to make TS-3006
work some structure internals must be accessed. What I would suggest is adding
another file, say SSLExt.cc, which contains any and all such internal access
so that (1) it alone is compiled without this flag and (2) localizes all
breakage in a single place to make it easier to use different SSL
implementations.
build with OPENSSL_NO_SSL_INTERN
Key: TS-3024
URL: https://issues.apache.org/jira/browse/TS-3024
Project: Traffic Server
Issue Type: Bug
Components: Build, SSL
Reporter: James Peach
Assignee: Susan Hinrichs
I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2279) proxy.config.exec_thread.affinity's values
[
https://issues.apache.org/jira/browse/TS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103207#comment-14103207
]
Brian Rectanus commented on TS-2279:
Used to be that 1 was sockets, but now that changed to 2 and 1 is now NUMA.
This seems to mean I will need to change my config (or something will migrate
it). I would have expected NUMA to be added as a new value (4) as to not
require changes to old configs. Why did all the values shift between 4.2 and
master?
proxy.config.exec_thread.affinity's values
--
Key: TS-2279
URL: https://issues.apache.org/jira/browse/TS-2279
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.1.0
The setting of {{proxy.config.exec_thread.affinity}} only has an affect when
traffic server was compiled with {{\-\-enable-hwloc}}. It has *no* affect at
all, not even a warning about its being ineffectual when setting that value
while trafficserver is *not* configured with {{--enable-hwloc}}.
Further, mgmt/RecordsConfig.cc defines a range of {{[0-1]}}:
{code}
{RECT_CONFIG, proxy.config.exec_thread.affinity, RECD_INT, 0,
RECU_RESTART_TS, RR_NULL, RECC_INT, [0-1], RECA_READ_ONLY}
{code}
but the code uses a range of [0-3]:
{code}
#if TS_USE_HWLOC
if (affinity != 0) {
int logical_ratio;
switch(affinity) {
case 3: // assign threads to logical cores
logical_ratio = 1;
break;
case 2: // assign threads to real cores
logical_ratio = pu / cu;
break;
case 1: // assign threads to sockets
default:
logical_ratio = pu / socket;
}
{code}
And finally, 1 is the default value, rather than issuing a warning about an
incorrect value.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2279) proxy.config.exec_thread.affinity's values
[
https://issues.apache.org/jira/browse/TS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103239#comment-14103239
]
Phil Sorber commented on TS-2279:
-
[~b1v1r],
Going from 4.2 to 5.0 we are allowed to change things like this. Probably
should have documented it better though.
They are currently ordered like they are because of the hierarchy that they
represent:
One or more NUMA zones in a machine
One or more sockets in a NUMA zone
One or more cores in a socket
One or more threads (processing units) in a core
Most people really wanted NUMA when they pick socket, and on a lot of hardware
they are 1:1 anyway.
Also, in 4.2 HWLOC doesn't really do anything. There was a long standing bug
discovered after it was released and the fix was considered too invasive to
consider a back port.
proxy.config.exec_thread.affinity's values
--
Key: TS-2279
URL: https://issues.apache.org/jira/browse/TS-2279
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.1.0
The setting of {{proxy.config.exec_thread.affinity}} only has an affect when
traffic server was compiled with {{\-\-enable-hwloc}}. It has *no* affect at
all, not even a warning about its being ineffectual when setting that value
while trafficserver is *not* configured with {{--enable-hwloc}}.
Further, mgmt/RecordsConfig.cc defines a range of {{[0-1]}}:
{code}
{RECT_CONFIG, proxy.config.exec_thread.affinity, RECD_INT, 0,
RECU_RESTART_TS, RR_NULL, RECC_INT, [0-1], RECA_READ_ONLY}
{code}
but the code uses a range of [0-3]:
{code}
#if TS_USE_HWLOC
if (affinity != 0) {
int logical_ratio;
switch(affinity) {
case 3: // assign threads to logical cores
logical_ratio = 1;
break;
case 2: // assign threads to real cores
logical_ratio = pu / cu;
break;
case 1: // assign threads to sockets
default:
logical_ratio = pu / socket;
}
{code}
And finally, 1 is the default value, rather than issuing a warning about an
incorrect value.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2584) failed assert transforming and caching negative response
[
https://issues.apache.org/jira/browse/TS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103251#comment-14103251
]
ASF subversion and git services commented on TS-2584:
-
Commit 2dbfeae15daa4f6675f4d3c7e10511cc872d077d in trafficserver's branch
refs/heads/master from [~nottheoilrig]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2dbfeae ]
TS-2584: Remove assert for negatively cached transformed content.
failed assert transforming and caching negative response
Key: TS-2584
URL: https://issues.apache.org/jira/browse/TS-2584
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Jack Bates
Assignee: Alan M. Carroll
Fix For: 5.1.0
If negative caching is enabled and you transform a negative response (for
example a null transform) there is a failed assert in
HttpTransact::set_headers_for_cache_write()
{noformat}
FATAL: HttpTransact.cc:4811: failed assert
`cache_info-response_get()-valid()`
proxy/.libs/lt-traffic_server - STACK TRACE:
lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
proxy/.libs/lt-traffic_server[0x82ff569]
/lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
Aborted (core dumped)
{noformat}
HttpTransact::handle_transform_ready() passes s-cache_info.transform_store
to HttpTransact::set_headers_for_cache_write()
The -valid() test at the top of HttpTransact::set_headers_for_cache_write()
fails so -create() gets called.
{code}
if (!cache_info-valid()) {
cache_info-create();
}
{code}
(s-cache_info.transform_store-m_alt is NULL. I didn't look into why this
is, is it expected?)
Because s-negative_caching is true, cache_info-response_set(response)
doesn't get called, instead the assert fails.
{code}
if (!s-negative_caching)
cache_info-response_set(response);
else {
ink_assert(cache_info-response_get()-valid());
}
{code}
Assuming the cache_info-valid() test can fail and s-negative_caching can be
true at the same time, one possible solution is to fix the logic so
cache_info-response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2584) failed assert transforming and caching negative response
[
https://issues.apache.org/jira/browse/TS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-2584.
-
Resolution: Fixed
failed assert transforming and caching negative response
Key: TS-2584
URL: https://issues.apache.org/jira/browse/TS-2584
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Jack Bates
Assignee: Alan M. Carroll
Fix For: 5.1.0
If negative caching is enabled and you transform a negative response (for
example a null transform) there is a failed assert in
HttpTransact::set_headers_for_cache_write()
{noformat}
FATAL: HttpTransact.cc:4811: failed assert
`cache_info-response_get()-valid()`
proxy/.libs/lt-traffic_server - STACK TRACE:
lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
proxy/.libs/lt-traffic_server[0x82ff569]
/lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
Aborted (core dumped)
{noformat}
HttpTransact::handle_transform_ready() passes s-cache_info.transform_store
to HttpTransact::set_headers_for_cache_write()
The -valid() test at the top of HttpTransact::set_headers_for_cache_write()
fails so -create() gets called.
{code}
if (!cache_info-valid()) {
cache_info-create();
}
{code}
(s-cache_info.transform_store-m_alt is NULL. I didn't look into why this
is, is it expected?)
Because s-negative_caching is true, cache_info-response_set(response)
doesn't get called, instead the assert fails.
{code}
if (!s-negative_caching)
cache_info-response_set(response);
else {
ink_assert(cache_info-response_get()-valid());
}
{code}
Assuming the cache_info-valid() test can fail and s-negative_caching can be
true at the same time, one possible solution is to fix the logic so
cache_info-response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2982) build error from gitmaster
[ https://issues.apache.org/jira/browse/TS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103274#comment-14103274 ] ASF subversion and git services commented on TS-2982: - Commit 14635098e981ab7b747b05a875a094e69c993186 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1463509 ] TS-2982: Interim cache compile errors. build error from gitmaster -- Key: TS-2982 URL: https://issues.apache.org/jira/browse/TS-2982 Project: Traffic Server Issue Type: Bug Reporter: bettydramit Assignee: Alan M. Carroll Fix For: 5.1.0 git master In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from MultiCache.cc:33: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from HostDB.cc:26: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' make[2]: *** [MultiCache.o] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2982) build error from gitmaster
[ https://issues.apache.org/jira/browse/TS-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2982. - Resolution: Fixed build error from gitmaster -- Key: TS-2982 URL: https://issues.apache.org/jira/browse/TS-2982 Project: Traffic Server Issue Type: Bug Reporter: bettydramit Assignee: Alan M. Carroll Fix For: 5.1.0 git master In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from MultiCache.cc:33: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' In file included from ../../iocore/cache/P_Cache.h:43, from ../../iocore/cluster/P_Cluster.h:31, from P_HostDB.h:38, from HostDB.cc:26: ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_in_progress(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:491: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_failed(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:496: error: 'union INK_MD5' has no member named 'word' ../../iocore/cache/P_CacheVol.h: In member function 'void Vol::set_migrate_done(MigrateToInterimCache*)': ../../iocore/cache/P_CacheVol.h:501: error: 'union INK_MD5' has no member named 'word' make[2]: *** [MultiCache.o] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-3025) Segmentation fault
bettydramit created TS-3025:
---
Summary: Segmentation fault
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Reporter: bettydramit
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value optimized
out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0, event=104,
data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0, vc=0x2aab20a63310,
thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-3025:
Affects Version/s: 5.1.0
Segmentation fault
--
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-3025:
Labels: crash (was: )
Segmentation fault
--
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103308#comment-14103308 ] ASF subversion and git services commented on TS-2905: - Commit f2facb7f603df27e8dc7613497887bc40896f9d9 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f2facb7 ] TS-2905: Fix IP logging to print '0' instead of error text. Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.2.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2905. - Resolution: Fixed Fix Version/s: (was: 5.2.0) 5.1.0 Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.1.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2905) Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT
[ https://issues.apache.org/jira/browse/TS-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103309#comment-14103309 ] Alan M. Carroll commented on TS-2905: - Yeah, if the IP address is missing (as with a TCP_HIT, no origin server address) an invalid IP address is put in the binary log and then generates that error text when logged. I changed the logging logic to print a literal '0' in that case instead. Logging Fields (pqsi/shi) displays *Not IP address [0]* during TCP_HIT Key: TS-2905 URL: https://issues.apache.org/jira/browse/TS-2905 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Avinash Katika Assignee: James Peach Priority: Minor Fix For: 5.1.0 When we are trying to log the fields(pqsi/shi) in access logs during TCP_HIT the value being displayed is *Not IP address [0]*.But we expect value displayed to be 0 as per the documentation. Version being used:4.2.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
