[jira] [Commented] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055888#comment-14055888
]
Wei Sun commented on TS-2924:
-
Actually, for the second case, it's no need to disable ssl protocol by given a
dedicated shorter cipher suite. We have to disable tls1_1 and tls1_2 to fix the
first issue. After disabling some protocols, ats client and origin are still
able to negotiate an agreeable protocol, the lower of that suggested by the ats
in the client hello and the highest supported by the origin will be chosen
afterwards, and the protocols are compatible. And the default workaround I
(https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4fcdd66fff5fea0cfa1055c6680a76a4303f28a2;hp=102302b05b2ea9c46a29be8a1451b7d1d6e3aa78)
in openssl doesn't fix the second hang issue, workaround II
(https://github.com/openssl/openssl/commit/89bd25eb26bbc2ebceb4cd892e7453337804820c)
is just to chop the supported ciphers, I think it is even worse than a
preferred cipher suite.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055888#comment-14055888
]
Wei Sun edited comment on TS-2924 at 7/9/14 6:18 AM:
-
Actually, for the second case, it's no need to disable ssl protocol by given a
dedicated shorter cipher suite. We have to disable tls1_1 and tls1_2 to fix the
first issue. After disabling some protocols, ats client and origin are still
able to negotiate an agreeable protocol, the lower of that suggested by the ats
in the client hello and the highest supported by the origin will be chosen
afterwards, and the protocols are compatible.
For the openssl workarounds, the default fix I
(https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4fcdd66fff5fea0cfa1055c6680a76a4303f28a2;hp=102302b05b2ea9c46a29be8a1451b7d1d6e3aa78)
doesn't fix the second hang issue, workaround II
(https://github.com/openssl/openssl/commit/89bd25eb26bbc2ebceb4cd892e7453337804820c)
is to chop the supported ciphers, I think it is even worse than a preferred
cipher suite.
was (Author: sunwei):
Actually, for the second case, it's no need to disable ssl protocol by given a
dedicated shorter cipher suite. We have to disable tls1_1 and tls1_2 to fix the
first issue. After disabling some protocols, ats client and origin are still
able to negotiate an agreeable protocol, the lower of that suggested by the ats
in the client hello and the highest supported by the origin will be chosen
afterwards, and the protocols are compatible. And the default workaround I
(https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4fcdd66fff5fea0cfa1055c6680a76a4303f28a2;hp=102302b05b2ea9c46a29be8a1451b7d1d6e3aa78)
in openssl doesn't fix the second hang issue, workaround II
(https://github.com/openssl/openssl/commit/89bd25eb26bbc2ebceb4cd892e7453337804820c)
is just to chop the supported ciphers, I think it is even worse than a
preferred cipher suite.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Sun updated TS-2924:
Attachment: TS-2924.diff
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
Attachments: TS-2924.diff
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055827#comment-14055827
]
Sudheer Vinukonda edited comment on TS-2924 at 7/9/14 3:39 PM:
---
I actually prefer not to have to disable any ssl protocol due to some (rare)
origins not supporting a particular version of the protocol. The origin should
still be able to negotiate an agreeable protocol version. Disabling the
protocols on ATS would affect all the origins (unless, the configurable cipher
list is made per origin and you know beforehand, which origins support a
specific cipher list/protocol list, which is next to impossible). I would
address the TLS hang issue with the openssl fixes and prefer not to have to
disable protocols.
Having said that, configurable ssl protocol/cipher suite for client context on
ATS, is a nice-to-have enhancement and I am fine with that, other than the
concern that, that should not be used to solve rare origin issues.
was (Author: sudheerv):
I actually prefer not to have to disable any ssl protocol due to some (rare)
origins not supporting a particular version of the protocol. The origin should
still be able to negotiate an agreeable protocol version. Disabling the
protocols on ATS would affect all the origins (unless, the configurable cipher
list is made per origin and you know beforehand, which origins support a
specific cipher list, which is next to impossible). I would address the TLS
hang issue with the openssl fixes and prefer not to have to disable protocols.
Having said that, configurable ssl protocol/cipher suite for client context on
ATS, is a nice-to-have enhancement and I am fine with that, other than the
concern that, that should not be used to solve rare origin issues.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
Attachments: TS-2924.diff
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056367#comment-14056367
]
Sudheer Vinukonda commented on TS-2924:
---
Disabling certain protocols or limiting the cipher suite affects ALL of the
origins, so, it doesn't sound like a good solution. If the origin can only
negotiate to an agreeable protocol, AFTER disabling some protocols, that
doesn't sound like negotiation, to begin with. If such origins are not wide
spread, perhaps, it's not even worth trying to fix the origin's bugs.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
Attachments: TS-2924.diff
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14055827#comment-14055827
]
Sudheer Vinukonda edited comment on TS-2924 at 7/9/14 3:50 PM:
---
I actually prefer not to have to disable any ssl protocol due to some (rare)
origins not supporting a particular version of the protocol. The origin should
still be able to negotiate an agreeable protocol version. Disabling the
protocols/ciphers on ATS would affect all the origins (unless, the configurable
protocol/cipher list is made per origin and you know beforehand, which origins
support a specific protocol/cipher list, which is next to impossible). I would
address the TLS hang issue with the openssl fixes and prefer not to have to
disable protocols/ciphers.
Having said that, configurable ssl protocol/cipher suite for client context on
ATS, is a nice-to-have enhancement and I am fine with that, other than the
concern that, that should not be used to solve rare origin issues.
was (Author: sudheerv):
I actually prefer not to have to disable any ssl protocol due to some (rare)
origins not supporting a particular version of the protocol. The origin should
still be able to negotiate an agreeable protocol version. Disabling the
protocols on ATS would affect all the origins (unless, the configurable cipher
list is made per origin and you know beforehand, which origins support a
specific cipher list/protocol list, which is next to impossible). I would
address the TLS hang issue with the openssl fixes and prefer not to have to
disable protocols.
Having said that, configurable ssl protocol/cipher suite for client context on
ATS, is a nice-to-have enhancement and I am fine with that, other than the
concern that, that should not be used to solve rare origin issues.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
Attachments: TS-2924.diff
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056367#comment-14056367
]
Sudheer Vinukonda edited comment on TS-2924 at 7/9/14 3:50 PM:
---
Disabling certain protocols or limiting the cipher suite affects ALL of the
origins, so, it doesn't sound like a good solution. If the origin can only
negotiate an agreeable protocol, AFTER disabling some protocols, that doesn't
sound like negotiation, to begin with. If such origins are not wide spread,
perhaps, it's not even worth trying to fix the origin's bugs.
was (Author: sudheerv):
Disabling certain protocols or limiting the cipher suite affects ALL of the
origins, so, it doesn't sound like a good solution. If the origin can only
negotiate to an agreeable protocol, AFTER disabling some protocols, that
doesn't sound like negotiation, to begin with. If such origins are not wide
spread, perhaps, it's not even worth trying to fix the origin's bugs.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
Attachments: TS-2924.diff
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2924) Configurable client's ssl protocols and cipher suite
[
https://issues.apache.org/jira/browse/TS-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056367#comment-14056367
]
Sudheer Vinukonda edited comment on TS-2924 at 7/9/14 3:51 PM:
---
Disabling certain protocols or limiting the cipher suite affects ALL of the
origins, so, it doesn't sound like a good solution. If the origin can only
negotiate an agreeable protocol, AFTER disabling some protocols, that doesn't
sound like negotiation, to begin with. If such origins are not wide spread,
perhaps, it's not even worth trying to fix these kind of origin bugs.
was (Author: sudheerv):
Disabling certain protocols or limiting the cipher suite affects ALL of the
origins, so, it doesn't sound like a good solution. If the origin can only
negotiate an agreeable protocol, AFTER disabling some protocols, that doesn't
sound like negotiation, to begin with. If such origins are not wide spread,
perhaps, it's not even worth trying to fix the origin's bugs.
Configurable client's ssl protocols and cipher suite
Key: TS-2924
URL: https://issues.apache.org/jira/browse/TS-2924
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Wei Sun
Labels: yahoo
Attachments: TS-2924.diff
A few old origins cannot support the latest ssl protocols well, ats is
expected to be able to configure dedicated cipher suite and protocols for SSL
client context.
{code}
e.g. Enable SSLv3/TLSv1/TLSv1_1/TLSv1_2
map http://foo1.com https://www.bankadviser.com/scbteod/scbteod_logo.GIF
map http://foo2.com
https://applications.bancopopular.com/images/emails/fb-share-button.jpg
curl -H 'Host: foo1.com' http://localhost:8080/ -v // failed to setup ssl
connection to origin
curl -H 'Host: foo2.com' http://localhost:8080/ -v //SSL connection hang
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2930) Missing hostname in ts.client_request.get_url()
Nikolai Gorchilov created TS-2930:
-
Summary: Missing hostname in ts.client_request.get_url()
Key: TS-2930
URL: https://issues.apache.org/jira/browse/TS-2930
Project: Traffic Server
Issue Type: Bug
Components: Lua, Plugins, TS API
Reporter: Nikolai Gorchilov
ts.client_request.get_uri() omits hostname from the returned url - responds
with http:///pathname?parameters; instead of
http://hostname/pathname?parameters;. This happens in the context of early
state hooks up to and including TS_HTTP_POST_REMAP_HOOK. When cacheurl plugin
is used, hostname is always omitted even in states after post_remap.
Here're the steps to reproduce the problem - a global lua plugin
(plugins.config):
==[cut]==
function do_global_txn_start()
print('==[cut]==')
print ('do_global_txt_start: ' .. ts.client_request.get_url())
end
function do_global_txn_close()
print ('do_global_txn_close: ' .. ts.client_request.get_url())
print('==[cut]==')
end
function do_global_os_dns()
print ('do_global_os_dns: ' .. ts.client_request.get_url())
end
function do_global_pre_remap()
print ('do_global_pre_remap: ' .. ts.client_request.get_url())
end
function do_global_post_remap()
print ('do_global_post_remap: ' .. ts.client_request.get_url())
end
function do_global_read_request()
print ('do_global_read_request: ' .. ts.client_request.get_url())
end
function do_global_send_request()
print ('do_global_send_request: ' .. ts.client_request.get_url())
end
function do_global_read_response()
print ('do_global_read_response: ' .. ts.client_request.get_url())
end
function do_global_send_response()
print ('do_global_send_response: ' .. ts.client_request.get_url())
end
function do_global_cache_lookup_complete()
print ('do_global_cache_lookup_complete: ' ..
ts.client_request.get_url())
end
function do_global_read_cache()
print ('do_global_read_cache: ' .. ts.client_request.get_url())
end
Requesting same URL -
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png - in 4
different scenarios:
1. empty cache (MISS) without cacheurl.so activated
2. HIT request without cacheurl.so activated
3. empty cache (MISS) with cacheurl.so activated
4. HIT request with cacheurl.so activated
Here's my traffic.out output:
1. MISS without cacheurl.so
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
2. HIT without cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_cache:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
3. MISS with cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close: http:///os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
4. HIT
[jira] [Updated] (TS-2930) Missing hostname in ts.client_request.get_url()
[
https://issues.apache.org/jira/browse/TS-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Gorchilov updated TS-2930:
--
Description:
ts.client_request.get_uri() omits hostname from the returned url - responds
with http:///pathname?parameters; instead of
http://hostname/pathname?parameters;. This happens in the context of early
state hooks up to and including TS_HTTP_POST_REMAP_HOOK.
In case of cacheurl.so rewrite on the URL, hostname reamains empty even after
post_remap.
Here're the steps to reproduce the problem - a global lua plugin
(plugins.config):
==[cut]==
function do_global_txn_start()
print('==[cut]==')
print ('do_global_txt_start: ' .. ts.client_request.get_url())
end
function do_global_txn_close()
print ('do_global_txn_close: ' .. ts.client_request.get_url())
print('==[cut]==')
end
function do_global_os_dns()
print ('do_global_os_dns: ' .. ts.client_request.get_url())
end
function do_global_pre_remap()
print ('do_global_pre_remap: ' .. ts.client_request.get_url())
end
function do_global_post_remap()
print ('do_global_post_remap: ' .. ts.client_request.get_url())
end
function do_global_read_request()
print ('do_global_read_request: ' .. ts.client_request.get_url())
end
function do_global_send_request()
print ('do_global_send_request: ' .. ts.client_request.get_url())
end
function do_global_read_response()
print ('do_global_read_response: ' .. ts.client_request.get_url())
end
function do_global_send_response()
print ('do_global_send_response: ' .. ts.client_request.get_url())
end
function do_global_cache_lookup_complete()
print ('do_global_cache_lookup_complete: ' ..
ts.client_request.get_url())
end
function do_global_read_cache()
print ('do_global_read_cache: ' .. ts.client_request.get_url())
end
Requesting same URL -
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png - in 4
different scenarios:
1. empty cache (MISS) without cacheurl.so activated
2. HIT request without cacheurl.so activated
3. empty cache (MISS) with cacheurl.so activated
4. HIT request with cacheurl.so activated
Here's my traffic.out output:
1. MISS without cacheurl.so
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
2. HIT without cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_cache:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
3. MISS with cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close: http:///os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
4. HIT with cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap:
[jira] [Updated] (TS-2930) Missing hostname in ts.client_request.get_url()
[
https://issues.apache.org/jira/browse/TS-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Gorchilov updated TS-2930:
--
Description:
ts.client_request.get_uri() omits hostname from the returned url - responds
with http:///pathname?parameters; instead of
http://hostname/pathname?parameters;. This happens in the context of early
state hooks up to and including TS_HTTP_POST_REMAP_HOOK.
In case of cacheurl.so rewrite on the URL, hostname reamains empty even after
post_remap.
Here're the steps to reproduce the problem - a global lua plugin
(plugins.config):
==[cut]==
function do_global_txn_start()
print('==[cut]==')
print ('do_global_txt_start: ' .. ts.client_request.get_url())
end
function do_global_txn_close()
print ('do_global_txn_close: ' .. ts.client_request.get_url())
print('==[cut]==')
end
function do_global_os_dns()
print ('do_global_os_dns: ' .. ts.client_request.get_url())
end
function do_global_pre_remap()
print ('do_global_pre_remap: ' .. ts.client_request.get_url())
end
function do_global_post_remap()
print ('do_global_post_remap: ' .. ts.client_request.get_url())
end
function do_global_read_request()
print ('do_global_read_request: ' .. ts.client_request.get_url())
end
function do_global_send_request()
print ('do_global_send_request: ' .. ts.client_request.get_url())
end
function do_global_read_response()
print ('do_global_read_response: ' .. ts.client_request.get_url())
end
function do_global_send_response()
print ('do_global_send_response: ' .. ts.client_request.get_url())
end
function do_global_cache_lookup_complete()
print ('do_global_cache_lookup_complete: ' ..
ts.client_request.get_url())
end
function do_global_read_cache()
print ('do_global_read_cache: ' .. ts.client_request.get_url())
end
Requesting same URL -
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png - in 4
different scenarios:
1. empty cache (MISS) without cacheurl.so activated
2. HIT request without cacheurl.so activated
3. empty cache (MISS) with cacheurl.so activated
4. HIT request with cacheurl.so activated
cacheurl.config consists the following:
^http://[^\/]*(yimg\.com)/(.*) http://$1.internal/$2
Here's my traffic.out output:
1. MISS without cacheurl.so
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
2. HIT without cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_cache:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close:
http://l.yimg.com/os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
3. MISS with cacheurl.so:
==[cut]==
do_global_txt_start: /
do_global_read_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_pre_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_post_remap: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_cache_lookup_complete:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_os_dns: http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_send_request:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_read_response:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_send_response:
http:///os/mit/media/m/base/images/transparent-1093278.png
do_global_txn_close: http:///os/mit/media/m/base/images/transparent-1093278.png
==[cut]==
4. HIT with cacheurl.so:
==[cut]==
do_global_txt_start: /
[jira] [Updated] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2780:
--
Attachment: (was: TS-2780.diff)
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.1.0
Attachments: ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2780:
--
Attachment: TS-2780.diff
Added code to cleanup a request when sending an error message. This is needed,
since, the client may continue to send data frames after a status message which
might result in a crash in TSFetchWrite() (since a FetchSM may not have been
created when sending status)
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.1.0
Attachments: TS-2780.diff, ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2883:
--
Attachment: (was: TS-2883.diff)
core dump in TSFetchCreate()
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
Labels: crash
Fix For: 5.1.0
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
#11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
event=100, edata=value optimized out) at SpdyClientSession.cc:236
#12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event=value
optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 read_signal_and_update (this=0x2b86fc1d2cf0, event=value optimized out)
at UnixNetVConnection.cc:138
#14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
event=value optimized out) at UnixNetVConnection.cc:914
#15 0x006fe66f in SSLNetVConnection::net_read_io
(this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
SSLNetVConnection.cc:294
#16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
event=value optimized out, e=value optimized out) at UnixNet.cc:399
#17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
calling_code=5) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
at UnixEThread.cc:145
#19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
UnixEThread.cc:269
#20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
#21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
#22 0x00361a0e894d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2883:
--
Attachment: TS-2883.diff
Moved some error logs out to patch in TS-2780 to avoid conflicts.
core dump in TSFetchCreate()
Key: TS-2883
URL: https://issues.apache.org/jira/browse/TS-2883
Project: Traffic Server
Issue Type: Bug
Components: Core, SPDY
Reporter: Sudheer Vinukonda
Labels: crash
Fix For: 5.1.0
Attachments: TS-2883.diff
{code}
(gdb) bt
#0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
#1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at ../lib/ts/Allocator.h:117
#2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
url=0x2b865d64f228
https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeom=BatchExecutewssid=nG7kmTWsJCDaction=compose_0_savedraftactionCount=88debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8deb;...,
version=0x2b865da5ace8 HTTP/1.1, client_addr=value optimized out,
flags=value optimized out) at InkAPI.cc:7289
#3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
#4 0x005f1faa in spdy_process_syn_stream_frame (session=value
optimized out, type=value optimized out, frame=value optimized out,
user_data=0x2b86821e2120)
at SpdyCallbacks.cc:295
#5 spdy_on_ctrl_recv_callback (session=value optimized out, type=value
optimized out, frame=value optimized out, user_data=0x2b86821e2120) at
SpdyCallbacks.cc:335
#6 0x00738050 in spdylay_session_on_syn_stream_received
(session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
#7 0x00738d57 in spdylay_session_process_ctrl_frame
(session=0x2b865defce10, in=0x2b858f987a90 \200\003, inlen=value optimized
out) at spdylay_session.c:2246
#8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
\200\003, inlen=value optimized out) at spdylay_session.c:2805
#9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
spdylay_session.c:2828
#10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
edata=value optimized out) at SpdyClientSession.cc:279
#11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
event=100, edata=value optimized out) at SpdyClientSession.cc:236
#12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event=value
optimized out) at ../../iocore/eventsystem/I_Continuation.h:146
#13 read_signal_and_update (this=0x2b86fc1d2cf0, event=value optimized out)
at UnixNetVConnection.cc:138
#14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
event=value optimized out) at UnixNetVConnection.cc:914
#15 0x006fe66f in SSLNetVConnection::net_read_io
(this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
SSLNetVConnection.cc:294
#16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
event=value optimized out, e=value optimized out) at UnixNet.cc:399
#17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
calling_code=5) at I_Continuation.h:146
#18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
at UnixEThread.cc:145
#19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
UnixEThread.cc:269
#20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
#21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
#22 0x00361a0e894d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056543#comment-14056543
]
Bryan Call commented on TS-2780:
From dev@
{code}
Good suggestion - will update and resubmit the patch.
Thank you,
Sudheer
On 7/8/14, 12:38 PM, James Peach jpe...@apache.org wrote:
A helper function would make this cleaner:
SpdyRequest *
SpdyClientSession::find_request(int streamid) {
mapint32_t, SpdyRequest*::iterator iter =
this-req_map.find(streamid);
return iter == this-req_map.end() ? NULL : iter-second;
}
{code}
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.1.0
Attachments: TS-2780.diff, ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056581#comment-14056581
]
ASF subversion and git services commented on TS-2780:
-
Commit 59d0e65224860cd906f04ed18aed4951baba05ba in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=59d0e65 ]
Revert TS-2780: Core dump in SpdyRequest::clear() in production testing of
SPDY
This reverts commit c9d4433531767c9b5f6db42b488af4552bc5c4a9.
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.1.0
Attachments: TS-2780.diff, ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056582#comment-14056582
]
ASF subversion and git services commented on TS-2780:
-
Commit fbf966eb603e2a202fe91144bd1a098fec628a6e in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fbf966e ]
TS-2780: Core dump in SpdyRequest::clear() in production testing of SPDY
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.1.0
Attachments: TS-2780.diff, ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2780) Core dump in SpdyRequest::clear() in production testing of SPDY
[
https://issues.apache.org/jira/browse/TS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056583#comment-14056583
]
ASF subversion and git services commented on TS-2780:
-
Commit 993bf5b23757abe95a657e0eee22c914a0964dbf in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=993bf5b ]
updated changes to include TS-2780
Core dump in SpdyRequest::clear() in production testing of SPDY
---
Key: TS-2780
URL: https://issues.apache.org/jira/browse/TS-2780
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Labels: spdy, yahoo
Fix For: 5.1.0
Attachments: TS-2780.diff, ts2780.diff
Noticed the below core dump in SpdyRequest::clear() during production testing
on our proxy platform.
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3420a0f500)[0x2b47cff7d500]
/home/y/bin/traffic_server(_ZN11SpdyRequest5clearEv+0x14)[0x5d06d4]
/home/y/bin/traffic_server(_ZN6SpdySM5clearEv+0x34)[0x5d0b84]
/home/y/bin/traffic_server[0x5d13d1]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x6efbcd]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xc76)[0x6df3e6]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e6b12]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aaf]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x715453]
/home/y/bin/traffic_server[0x713e5a]
/lib64/libpthread.so.0(+0x3420a07851)[0x2b47cff75851]
/lib64/libc.so.6(clone+0x6d)[0x34202e894d]
{code}
gdb output shows that req may be a null pointer in SpdySM::clear()
{code}
(gdb) bt
#0 SpdyRequest::clear (this=0x0) at SpdySM.cc:44
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
#2 0x005d13d1 in spdy_default_handler (contp=value optimized out,
event=TS_EVENT_VCONN_INACTIVITY_TIMEOUT, edata=value optimized out) at
SpdySM.cc:258
#3 0x006eeabb in handleEvent (event=value optimized out,
vc=0x2aefcc141ca0) at ../../iocore/eventsystem/I_Continuation.h:146
#4 read_signal_and_update (event=value optimized out, vc=0x2aefcc141ca0)
at UnixNetVConnection.cc:216
#5 0x006f3cd4 in UnixNetVConnection::mainEvent (this=0x2aefcc141ca0,
event=value optimized out, e=value optimized out) at
UnixNetVConnection.cc:1152
#6 0x006e7d0e in handleEvent (this=0x1634af0, event=value optimized
out, e=0x136e850) at ../../iocore/eventsystem/I_Continuation.h:146
#7 InactivityCop::check_inactivity (this=0x1634af0, event=value optimized
out, e=0x136e850) at UnixNet.cc:67
#8 0x00714aaf in handleEvent (this=0x2aef48f91010, e=0x136e850,
calling_code=2) at I_Continuation.h:146
#9 EThread::process_event (this=0x2aef48f91010, e=0x136e850, calling_code=2)
at UnixEThread.cc:145
#10 0x00715623 in EThread::execute (this=0x2aef48f91010) at
UnixEThread.cc:224
#11 0x00713e5a in spawn_thread_internal (a=0x163d000) at Thread.cc:88
#12 0x2aed0a8a1851 in start_thread () from /lib64/libpthread.so.0
#13 0x0034202e894d in clone () from /lib64/libc.so.6
(gdb) print this
$1 = (SpdyRequest * const) 0x0
(gdb) up
#1 0x005d0b84 in SpdySM::clear (this=0x2aefdc4b46a0) at SpdySM.cc:116
116 in SpdySM.cc
(gdb) print req
$2 = (SpdyRequest *) 0x0
(gdb) print iter
$3 = {first = 25, second = }
(gdb) print req_map
$4 = std::map with 3 elements = {
[1] = 0x2aefd81e5ae0,
[25] = 0x0,
[27] = 0x0
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14056670#comment-14056670 ] Otto van der Schaaf commented on TS-2926: - Done, I submitted the grant file to secret...@apache.org this afternoon 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 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-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 ] Otto van der Schaaf updated TS-2926: Description: 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 was: 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 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 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 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] [Created] (TS-2931) plugin metrics fail after a crash
James Peach created TS-2931:
---
Summary: plugin metrics fail after a crash
Key: TS-2931
URL: https://issues.apache.org/jira/browse/TS-2931
Project: Traffic Server
Issue Type: Bug
Components: Plugins, TS API
Reporter: James Peach
If a plugin uses {{TSStatFindName}} followed by {{TSStatCreate}},
{{TSStatFindName}} can return 0 for all the metric IDs after a
{{traffic_server}} crash.
AFAICT this will happen every time with the following conditions:
1. traffic_manager has pulled the plugin stat records from traffic_server
2. traffic_server crashes
When traffic_server comes back up, it pulls the records from traffic_manager.
traffic_manager sends the records including the rsb_id field. However,
RecForceInsert() does not copy the rsb_id field from the message to the actual
record. There are 2 reasonable fixes:
- We could not propagate the 'registered' flag for records that we on. This
forces the code to re-register, which will bring the stats back to the correct
state.
- We could ensure that we copy the rsb_id field so that stat lookups succeed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2931) plugin metrics fail after a crash
[
https://issues.apache.org/jira/browse/TS-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2931:
Fix Version/s: 5.1.0
Assignee: James Peach
plugin metrics fail after a crash
-
Key: TS-2931
URL: https://issues.apache.org/jira/browse/TS-2931
Project: Traffic Server
Issue Type: Bug
Components: Plugins, TS API
Reporter: James Peach
Assignee: James Peach
Fix For: 5.1.0
If a plugin uses {{TSStatFindName}} followed by {{TSStatCreate}},
{{TSStatFindName}} can return 0 for all the metric IDs after a
{{traffic_server}} crash.
AFAICT this will happen every time with the following conditions:
1. traffic_manager has pulled the plugin stat records from traffic_server
2. traffic_server crashes
When traffic_server comes back up, it pulls the records from traffic_manager.
traffic_manager sends the records including the rsb_id field. However,
RecForceInsert() does not copy the rsb_id field from the message to the
actual record. There are 2 reasonable fixes:
- We could not propagate the 'registered' flag for records that we on. This
forces the code to re-register, which will bring the stats back to the
correct state.
- We could ensure that we copy the rsb_id field so that stat lookups succeed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2932) specify the build version at build time
[
https://issues.apache.org/jira/browse/TS-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2932:
Priority: Minor (was: Major)
Fix Version/s: 5.1.0
Assignee: James Peach
specify the build version at build time
---
Key: TS-2932
URL: https://issues.apache.org/jira/browse/TS-2932
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 5.1.0
I'd like to publish the specific tag that my internal traffic server build
used. Adding a {{--with-build-number}} configuration option so that this can
be published in {{proxy.node.version.manager.build_number}} and
{{proxy.process.version.server.build_number}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2932) specify the build version at build time
James Peach created TS-2932:
---
Summary: specify the build version at build time
Key: TS-2932
URL: https://issues.apache.org/jira/browse/TS-2932
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
I'd like to publish the specific tag that my internal traffic server build
used. Adding a {{--with-build-number}} configuration option so that this can be
published in {{proxy.node.version.manager.build_number}} and
{{proxy.process.version.server.build_number}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2932) specify the build number at build time
[
https://issues.apache.org/jira/browse/TS-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2932:
Summary: specify the build number at build time (was: specify the build
version at build time)
specify the build number at build time
--
Key: TS-2932
URL: https://issues.apache.org/jira/browse/TS-2932
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 5.1.0
I'd like to publish the specific tag that my internal traffic server build
used. Adding a {{--with-build-number}} configuration option so that this can
be published in {{proxy.node.version.manager.build_number}} and
{{proxy.process.version.server.build_number}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2649) add certificate chain loading to SSL client
[
https://issues.apache.org/jira/browse/TS-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056949#comment-14056949
]
ASF subversion and git services commented on TS-2649:
-
Commit 06f5b3f8a5a85e2e7e3f0e5cf910e944ea87842e in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=06f5b3f ]
TS-2649: use certificate chain loading everywhere
Use SSL_CTX_use_certificate_chain_file() everywhere we load a SSL
certificate. This lets the operator use a certificate chain in a
single file for both the SSL client and server.
add certificate chain loading to SSL client
---
Key: TS-2649
URL: https://issues.apache.org/jira/browse/TS-2649
Project: Traffic Server
Issue Type: New Feature
Components: SSL
Affects Versions: 5.0.0
Reporter: James Peach
Assignee: James Peach
Fix For: 5.1.0
The SSL client has no way to load a chain file, so sending a SSL client
certificate invariably fails. It works when we use
{{SSL_CTX_use_certificate_chain_file}} to load the certificate, and that
seems to be current best practice with OpenSSL.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2931) plugin metrics fail after a crash
[
https://issues.apache.org/jira/browse/TS-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14056952#comment-14056952
]
ASF subversion and git services commented on TS-2931:
-
Commit d537357da69ee701c7165f0e1f07554e18324e1f in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d537357 ]
TS-2931: plugin metrics fail after a crash
If a plugin uses TSStatFindName followed by TSStatCreate, TSStatFindName
can return 0 for all the metric IDs after a traffic_server crash.
This will happen every time with the following conditions:
1. traffic_manager has pulled the stat records from traffic_server
2. traffic_server crashes
When traffic_server comes back up, it pulls the records from
traffic_manager. traffic_manager sends the records including the
rsb_id field. However, RecForceInsert() does not copy the rsb_id
field from the message to the actual record. Subsequent stat lookups
succeed because the stat is registered, but always receive a rsb_id
of 0.
The fix is to ensure that we copy the rsb_id field so that stat
lookups succeed.
plugin metrics fail after a crash
-
Key: TS-2931
URL: https://issues.apache.org/jira/browse/TS-2931
Project: Traffic Server
Issue Type: Bug
Components: Plugins, TS API
Reporter: James Peach
Assignee: James Peach
Fix For: 5.1.0
If a plugin uses {{TSStatFindName}} followed by {{TSStatCreate}},
{{TSStatFindName}} can return 0 for all the metric IDs after a
{{traffic_server}} crash.
AFAICT this will happen every time with the following conditions:
1. traffic_manager has pulled the plugin stat records from traffic_server
2. traffic_server crashes
When traffic_server comes back up, it pulls the records from traffic_manager.
traffic_manager sends the records including the rsb_id field. However,
RecForceInsert() does not copy the rsb_id field from the message to the
actual record. There are 2 reasonable fixes:
- We could not propagate the 'registered' flag for records that we on. This
forces the code to re-register, which will bring the stats back to the
correct state.
- We could ensure that we copy the rsb_id field so that stat lookups succeed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2649) add certificate chain loading to SSL client
[
https://issues.apache.org/jira/browse/TS-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2649.
-
Resolution: Fixed
add certificate chain loading to SSL client
---
Key: TS-2649
URL: https://issues.apache.org/jira/browse/TS-2649
Project: Traffic Server
Issue Type: New Feature
Components: SSL
Affects Versions: 5.0.0
Reporter: James Peach
Assignee: James Peach
Fix For: 5.1.0
The SSL client has no way to load a chain file, so sending a SSL client
certificate invariably fails. It works when we use
{{SSL_CTX_use_certificate_chain_file}} to load the certificate, and that
seems to be current best practice with OpenSSL.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2931) plugin metrics fail after a crash
[
https://issues.apache.org/jira/browse/TS-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2931.
-
Resolution: Fixed
plugin metrics fail after a crash
-
Key: TS-2931
URL: https://issues.apache.org/jira/browse/TS-2931
Project: Traffic Server
Issue Type: Bug
Components: Plugins, TS API
Reporter: James Peach
Assignee: James Peach
Fix For: 5.1.0
If a plugin uses {{TSStatFindName}} followed by {{TSStatCreate}},
{{TSStatFindName}} can return 0 for all the metric IDs after a
{{traffic_server}} crash.
AFAICT this will happen every time with the following conditions:
1. traffic_manager has pulled the plugin stat records from traffic_server
2. traffic_server crashes
When traffic_server comes back up, it pulls the records from traffic_manager.
traffic_manager sends the records including the rsb_id field. However,
RecForceInsert() does not copy the rsb_id field from the message to the
actual record. There are 2 reasonable fixes:
- We could not propagate the 'registered' flag for records that we on. This
forces the code to re-register, which will bring the stats back to the
correct state.
- We could ensure that we copy the rsb_id field so that stat lookups succeed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
