[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022002#comment-13022002
]
qianshi commented on TS-718:
hi lief, thank you for your advice. I think we should have a complete solution
for ssl support, maybe we need a deeply discussion for it.
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 2.1.8
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Compression: 1 (zlib compression)
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
[jira] [Issue Comment Edited] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022002#comment-13022002
]
qianshi edited comment on TS-718 at 4/20/11 7:10 AM:
-
hi lief, thank you for your advice. I think we should have a complete solution
for ssl support, maybe we need a deeply discussion for it.
https://cwiki.apache.org/TS/sslsessionresumption.html
was (Author: qianshi):
hi lief, thank you for your advice. I think we should have a complete
solution for ssl support, maybe we need a deeply discussion for it.
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 2.1.8
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Compression: 1 (zlib compression)
Start Time: 1300962675
Timeout : 300 (sec)
[jira] [Updated] (TS-168) LogBuffer.h/LogObject.h overload operator new and do object initialization there using iObject which is evil
[ https://issues.apache.org/jira/browse/TS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-168: - Fix Version/s: (was: 2.1.8) 2.1.9 LogBuffer.h/LogObject.h overload operator new and do object initialization there using iObject which is evil Key: TS-168 URL: https://issues.apache.org/jira/browse/TS-168 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: John Plevyak Assignee: John Plevyak Priority: Critical Fix For: 2.1.9 Attachments: LogBuff.diff In header LogBuffer.h the classes iObject/iObjectActivator/iLogBufferData need to be cleaned up. This code is terribly designed. Nobody should ever do object initialization in an overloaded new operator. This caused TS-159. The logging code was designed to be completely lockless on the critical path and not to do any malloc/new (which typically involve locks) and this code breaks that design. Basically, this should be rewritten, perhaps someone for Y! could attach the patch which added this junk so it can be backed out and whatever real functionality it added, added in a reasonable way. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022557#comment-13022557
]
Leif Hedstrom commented on TS-718:
--
If I may make a few additional suggestions:
1) We should try to figure out why RHEL5 / CentOS5 doesn't work with session
cache.
2) In the patch, maybe instead of using a time based expire, just implement an
LRU on top of the hash, so that you simply evict the oldest (least frequently
used) session object. This simplifies eviction by a lot, and avoids that entire
configuration option. It also means you will retain an optimal number of
session keys in the cache.
3) Do we really need to base-64 encode the session ID? As you've notived, that
causes an xmalloc() which you then have to xfree() every time you do a lookup
(or insert). Can't we just use the session ID as-is as the hash key?
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 2.1.8
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
[jira] [Updated] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-718:
-
Fix Version/s: (was: 2.1.8)
2.1.9
I'm going to move this out to v2.1.9 for now, we can always move it back if we
decide to.
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 2.1.9
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Compression: 1 (zlib compression)
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher
[jira] [Updated] (TS-739) Crash in ::write
[
https://issues.apache.org/jira/browse/TS-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-739:
-
Fix Version/s: (was: 2.1.9)
2.1.8
Crash in ::write
Key: TS-739
URL: https://issues.apache.org/jira/browse/TS-739
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 2.1.8
Opening another bug for this, it can still happen regardless of ccache on or
off.
My setup is fairly simple, mostly standard configs, but setup as a forward
proxy. When pointing my browser to use ATS as the proxy, and I go to
search.google.com and start typing in the search box, we sometimes segfault.
{code}
(gdb) bt
#0 0x003f2e60e1fd in write () from /lib64/libpthread.so.0
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
#3 0x0061443b in write_to_net_io (nh=0x76d15628,
vc=0x7fffe000bd70, thread=0x76d14010)
at UnixNetVConnection.cc:439
#4 0x0060c42a in NetHandler::mainNetEvent (this=0x76d15628,
event=value optimized out, e=value optimized out)
at UnixNet.cc:419
#5 0x006325e4 in handleEvent (this=0x76d14010, e=0xe846a0,
calling_code=5) at I_Continuation.h:146
#6 EThread::process_event (this=0x76d14010, e=0xe846a0, calling_code=5)
at UnixEThread.cc:140
#7 0x00632f73 in EThread::execute (this=0x76d14010) at
UnixEThread.cc:262
#8 0x0063142a in spawn_thread_internal (a=0xe770f0) at Thread.cc:85
#9 0x003f2e6068e0 in start_thread () from /lib64/libpthread.so.0
#10 0x003f2dee0c9d in clone () from /lib64/libc.so.6
#11 0x in ?? ()
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print fd
$3 = 45
(gdb) print buf
$4 = (void *) 0x7fffc9860b14
(gdb) print size
$5 = value optimized out
(gdb) frame 2
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
833 r = socketManager.write(con.fd, tiovec[0].iov_base,
tiovec[0].iov_len);
(gdb) print con.fd
$6 = 45
(gdb) print tiovec[0].iov_base
$7 = (void *) 0x7fffc9860b14
(gdb) print tiovec[0].iov_len
$8 = 1260
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print buf
$9 = (void *) 0x7fffc9860b14
(gdb) print *buf
Attempt to dereference a generic pointer.
(gdb) frame 2
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
833 r = socketManager.write(con.fd, tiovec[0].iov_base,
tiovec[0].iov_len);
(gdb) print tiovec[0].iov_base
$10 = (void *) 0x7fffc9860b14
(gdb) print *((char*)tiovec[0].iov_base)
$11 = 120 'x'
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print *((char*)buf)
$12 = 120 'x'
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-739) Crash in ::write
[
https://issues.apache.org/jira/browse/TS-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-739:
Assignee: Leif Hedstrom
Crash in ::write
Key: TS-739
URL: https://issues.apache.org/jira/browse/TS-739
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 2.1.8
Opening another bug for this, it can still happen regardless of ccache on or
off.
My setup is fairly simple, mostly standard configs, but setup as a forward
proxy. When pointing my browser to use ATS as the proxy, and I go to
search.google.com and start typing in the search box, we sometimes segfault.
{code}
(gdb) bt
#0 0x003f2e60e1fd in write () from /lib64/libpthread.so.0
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
#3 0x0061443b in write_to_net_io (nh=0x76d15628,
vc=0x7fffe000bd70, thread=0x76d14010)
at UnixNetVConnection.cc:439
#4 0x0060c42a in NetHandler::mainNetEvent (this=0x76d15628,
event=value optimized out, e=value optimized out)
at UnixNet.cc:419
#5 0x006325e4 in handleEvent (this=0x76d14010, e=0xe846a0,
calling_code=5) at I_Continuation.h:146
#6 EThread::process_event (this=0x76d14010, e=0xe846a0, calling_code=5)
at UnixEThread.cc:140
#7 0x00632f73 in EThread::execute (this=0x76d14010) at
UnixEThread.cc:262
#8 0x0063142a in spawn_thread_internal (a=0xe770f0) at Thread.cc:85
#9 0x003f2e6068e0 in start_thread () from /lib64/libpthread.so.0
#10 0x003f2dee0c9d in clone () from /lib64/libc.so.6
#11 0x in ?? ()
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print fd
$3 = 45
(gdb) print buf
$4 = (void *) 0x7fffc9860b14
(gdb) print size
$5 = value optimized out
(gdb) frame 2
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
833 r = socketManager.write(con.fd, tiovec[0].iov_base,
tiovec[0].iov_len);
(gdb) print con.fd
$6 = 45
(gdb) print tiovec[0].iov_base
$7 = (void *) 0x7fffc9860b14
(gdb) print tiovec[0].iov_len
$8 = 1260
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print buf
$9 = (void *) 0x7fffc9860b14
(gdb) print *buf
Attempt to dereference a generic pointer.
(gdb) frame 2
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
833 r = socketManager.write(con.fd, tiovec[0].iov_base,
tiovec[0].iov_len);
(gdb) print tiovec[0].iov_base
$10 = (void *) 0x7fffc9860b14
(gdb) print *((char*)tiovec[0].iov_base)
$11 = 120 'x'
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print *((char*)buf)
$12 = 120 'x'
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022576#comment-13022576
]
Leif Hedstrom commented on TS-702:
--
Yakov: I've played around with the patch too, and it seems good. Would you mind
providing an updated patch, addressing the issues raised by Alan and me? I'll
have this committed as soon as we get that.
Thanks!
FATAL: MIME.cc:1250: failed assert `j block_count`
-
Key: TS-702
URL: https://issues.apache.org/jira/browse/TS-702
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 2.0.1
Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
Kernel 2.6.26-2-amd64
Reporter: Ricky Chan
Priority: Critical
Fix For: 2.1.8
Attachments: trafficserver.2.1.7.too.many.mimefields.patch
I have 20 servers in a CDN farm which I brought live recently, I have noticed
with in a day 5 servers had this error reported in traffic.out. Essentially
aborting due to assertion failure. The server restarts (from traffic_cop).
This platform has not had any load go through it yet, it's running around
5MB/s a second with around 25 connection per second. So doing much.
I was going to migrate more traffic onto it, but holding off due to this
assertion issue.
Looking at the code, we have:
for (j=0; j block_count; j++) {
... with a condition which breaks out ..
}
ink_release_assert(j block_count)
So for this assert to be hit the entire list must be gone through without
triggering the break clause, i.e. j == block_count
I don't know this code well, is this a real bug or should the assert be there
(or j = block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-739) Crash in ::write
[
https://issues.apache.org/jira/browse/TS-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-739.
--
Resolution: Fixed
Marking this as fixed, after John's changes to the freelist pointers, I'm
unable to reproduce this bug. Reopen if this happens again.
Crash in ::write
Key: TS-739
URL: https://issues.apache.org/jira/browse/TS-739
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 2.1.8
Opening another bug for this, it can still happen regardless of ccache on or
off.
My setup is fairly simple, mostly standard configs, but setup as a forward
proxy. When pointing my browser to use ATS as the proxy, and I go to
search.google.com and start typing in the search box, we sometimes segfault.
{code}
(gdb) bt
#0 0x003f2e60e1fd in write () from /lib64/libpthread.so.0
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
#3 0x0061443b in write_to_net_io (nh=0x76d15628,
vc=0x7fffe000bd70, thread=0x76d14010)
at UnixNetVConnection.cc:439
#4 0x0060c42a in NetHandler::mainNetEvent (this=0x76d15628,
event=value optimized out, e=value optimized out)
at UnixNet.cc:419
#5 0x006325e4 in handleEvent (this=0x76d14010, e=0xe846a0,
calling_code=5) at I_Continuation.h:146
#6 EThread::process_event (this=0x76d14010, e=0xe846a0, calling_code=5)
at UnixEThread.cc:140
#7 0x00632f73 in EThread::execute (this=0x76d14010) at
UnixEThread.cc:262
#8 0x0063142a in spawn_thread_internal (a=0xe770f0) at Thread.cc:85
#9 0x003f2e6068e0 in start_thread () from /lib64/libpthread.so.0
#10 0x003f2dee0c9d in clone () from /lib64/libc.so.6
#11 0x in ?? ()
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print fd
$3 = 45
(gdb) print buf
$4 = (void *) 0x7fffc9860b14
(gdb) print size
$5 = value optimized out
(gdb) frame 2
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
833 r = socketManager.write(con.fd, tiovec[0].iov_base,
tiovec[0].iov_len);
(gdb) print con.fd
$6 = 45
(gdb) print tiovec[0].iov_base
$7 = (void *) 0x7fffc9860b14
(gdb) print tiovec[0].iov_len
$8 = 1260
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print buf
$9 = (void *) 0x7fffc9860b14
(gdb) print *buf
Attempt to dereference a generic pointer.
(gdb) frame 2
#2 UnixNetVConnection::load_buffer_and_write (this=0x7fffe000bd70,
towrite=1260, wattempted=@0x76c11c78,
total_wrote=@0x76c11c80, buf=value optimized out) at
UnixNetVConnection.cc:833
833 r = socketManager.write(con.fd, tiovec[0].iov_base,
tiovec[0].iov_len);
(gdb) print tiovec[0].iov_base
$10 = (void *) 0x7fffc9860b14
(gdb) print *((char*)tiovec[0].iov_base)
$11 = 120 'x'
(gdb) frame 1
#1 0x006102d8 in write (this=0x7fffe000bd70, towrite=1260,
wattempted=@0x76c11c78, total_wrote=@0x76c11c80,
buf=value optimized out) at
../../iocore/eventsystem/P_UnixSocketManager.h:207
207 if (likely((r =::write(fd, buf, size)) = 0))
(gdb) print *((char*)buf)
$12 = 120 'x'
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022578#comment-13022578
]
Ricky Chan commented on TS-702:
---
I am on annual leave and will be back on Wednesday the 27st, for any assistance
please contact isp.developm...@sns.bskyb.com.
Cheers.
FATAL: MIME.cc:1250: failed assert `j block_count`
-
Key: TS-702
URL: https://issues.apache.org/jira/browse/TS-702
Project: Traffic Server
Issue Type: Bug
Components: MIME
Affects Versions: 2.0.1
Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
Kernel 2.6.26-2-amd64
Reporter: Ricky Chan
Priority: Critical
Fix For: 2.1.8
Attachments: trafficserver.2.1.7.too.many.mimefields.patch
I have 20 servers in a CDN farm which I brought live recently, I have noticed
with in a day 5 servers had this error reported in traffic.out. Essentially
aborting due to assertion failure. The server restarts (from traffic_cop).
This platform has not had any load go through it yet, it's running around
5MB/s a second with around 25 connection per second. So doing much.
I was going to migrate more traffic onto it, but holding off due to this
assertion issue.
Looking at the code, we have:
for (j=0; j block_count; j++) {
... with a condition which breaks out ..
}
ink_release_assert(j block_count)
So for this assert to be hit the entire list must be gone through without
triggering the break clause, i.e. j == block_count
I don't know this code well, is this a real bug or should the assert be there
(or j = block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-716) Crash in Continuation::handleEvent
[
https://issues.apache.org/jira/browse/TS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022577#comment-13022577
]
Leif Hedstrom commented on TS-716:
--
If the original author of this ticket doesn't respond in a day or two, I'd like
to suggest we close this ticket, and we can reopen it later if necessary.
Crash in Continuation::handleEvent
---
Key: TS-716
URL: https://issues.apache.org/jira/browse/TS-716
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 2.1.7
Environment: CentOS 5.4 x86_64, 6 * 2T SATA Disks, 48G Memory
Reporter: Kissdev
Assignee: John Plevyak
Priority: Critical
Fix For: 2.1.8
Attachments: crasher.patch
ATS crashes with the following configuration:
- reverse proxy , storage: 6 raw devices (6*2T), 1 partition (2T)
- remap config:regex_map http://(.*) http://$1
The load : about 100Mbps, requests for top 4000 internet sites, mainly
html,js,pictures,flashes
Detail of crashes by core dump:
crash #1:
{code}
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
146 I_Continuation.h: No such file or directory.
in I_Continuation.h
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
#1 0x00702b80 in EThread::process_event (this=0x2b101010,
e=0x90f7170, calling_code=1) at UnixEThread.cc:140
#2 0x00702fa1 in EThread::execute (this=0x2b101010) at
UnixEThread.cc:232
#3 0x007024d2 in spawn_thread_internal (a=0x8d94a70) at Thread.cc:85
#4 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
#5 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
event=1, data=0x90f7170) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaaba360a11},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
{code}
crash #2:
{code}
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
event=1, data=0x154b5a80) at I_Continuation.h:146
#1 0x006db290 in InactivityCop::check_inactivity (this=0x154c8730,
event=2, e=0x154b5a80) at UnixNet.cc:57
#2 0x004dd1bb in Continuation::handleEvent (this=0x154c8730,
event=2, data=0x154b5a80) at I_Continuation.h:146
#3 0x00702b80 in EThread::process_event (this=0x2b606010,
e=0x154b5a80, calling_code=2) at UnixEThread.cc:140
#4 0x00702ec2 in EThread::execute (this=0x2b606010) at
UnixEThread.cc:217
#5 0x007024d2 in spawn_thread_internal (a=0x154852c0) at Thread.cc:85
#6 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
#7 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
event=1, data=0x154b5a80) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x16280061},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
(gdb)
{code}
crash #3:
{code}
(gdb) bt
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
event=2, data=0x5631120) at I_Continuation.h:146
#1 0x00702b80 in EThread::process_event (this=0x2abfc010,
e=0x5631120, calling_code=2) at UnixEThread.cc:140
#2 0x00702ec2 in EThread::execute (this=0x2abfc010) at
UnixEThread.cc:217
#3 0x0050917c in main (argc=3, argv=0x7fff0af6e3b8) at Main.cc:1962
(gdb) frame 0
#0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
event=2, data=0x5631120) at I_Continuation.h:146
146 in I_Continuation.h
(gdb) print *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab45df291},
handler = virtual table offset -1157442765409226770, this adjustment
-1157442765409226769,
handler_name = 0xefefefefefefefef Address 0xefefefefefefefef out of
bounds, mutex = {m_ptr = 0xefefefefefefefef}, link = {SLinkContinuation
= {
next = 0xefefefefefefefef}, prev =
[jira] [Commented] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022583#comment-13022583
]
Leif Hedstrom commented on TS-718:
--
Oddly enough, I think this is a problem with the OpenSSL libraries, and/or how
we use them (I don't know why it works with HTTPD on your box). But, here's the
thing, if you use openssl s_client using the native openssl binary
(/usr/bin/openssl), it fails for me regardless if I link ATS with RHEL5 OpenSSL
or if I use a custom install of OpenSSL v1.0.0d.
However, if I do the check using a good openssl binary, it works fine. E.g.
{code}
loki (18:45) 254/0 $ echo | openssl s_client -reconnect -connect centos5:443
21 | grep Cipher is
New, TLSv1/SSLv3, Cipher is AES256-SHA
Reused, TLSv1/SSLv3, Cipher is AES256-SHA
Reused, TLSv1/SSLv3, Cipher is AES256-SHA
Reused, TLSv1/SSLv3, Cipher is AES256-SHA
Reused, TLSv1/SSLv3, Cipher is AES256-SHA
Reused, TLSv1/SSLv3, Cipher is AES256-SHA
{code}
That's against ATS using OpenSSL v1.0.0d. But linking ATS with the native
OpenSSL libraries of RHEL5, I get the same result again, i.e. the server works
fine. So, as far as I can tell, it's really something broken with the openssl
client on RHEL5, at least how it interacts with ATS (I have no idea why it'd be
different talking to ATS vs HTTPD, maybe something with the certs or
something?).
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 2.1.9
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
[jira] [Created] (TS-744) Configurations to control SSL session reuse and cache size
Configurations to control SSL session reuse and cache size -- Key: TS-744 URL: https://issues.apache.org/jira/browse/TS-744 Project: Traffic Server Issue Type: New Feature Reporter: Leif Hedstrom Assignee: Leif Hedstrom I'd like to add to add two options as per TS-718 for OpenSSL session cache reuse to records.config: proxy.config.ssl.session_cache proxy.config.ssl.session_cache.size The first one (currently) will take two values, but can be extended with further features: 0 - No session cache 1 - Use OpenSSL native server session cache The second controls the session cache size, and defaults to 20480 (1024*20, which is the OpenSSL default). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-724) disk IO balance in v2.1.7
[
https://issues.apache.org/jira/browse/TS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022597#comment-13022597
]
John Plevyak commented on TS-724:
-
FYI a single document ends up on a single disk. If we could get the
per-partition cache stats we could see what ATS thought was going on.
disk IO balance in v2.1.7
-
Key: TS-724
URL: https://issues.apache.org/jira/browse/TS-724
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 2.1.7
Environment: reporting from users, and confirm within my testing evn.
v2.1.7 only
Reporter: Zhao Yongming
Priority: Critical
Fix For: 2.1.9
when multiple disk enabled, the disk IO will show much diff in v2.1.7, here
is my result on a 7 disk system result:
{code:none}
[root@cache189 ~]# iostat -x 5
Linux 2.6.18-164.11.1.el5 (cache189.cn8) 03/29/2011
avg-cpu: %user %nice %system %iowait %steal %idle
0.510.000.541.770.00 97.18
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz
avgqu-sz await svctm %util
sdb 0.00 0.00 11.80 0.00 360.80 0.0030.58
0.075.73 5.56 6.56
sdc 0.00 0.00 12.00 0.00 413.80 0.0034.48
0.075.42 5.30 6.36
sdd 0.00 0.00 11.60 1.40 375.80 820.8092.05
0.075.06 4.66 6.06
sde 0.00 0.00 13.00 14.00 722.60 8192.00 330.17
0.124.50 2.99 8.06
sdf 0.00 0.00 14.60 0.00 579.40 0.0039.68
0.117.48 7.04 10.28
sdg 0.00 0.00 49.20 0.00 18268.60 0.00 371.31
0.081.66 0.54 2.66
sdb 0.00 0.00 11.60 0.00 253.60 0.0021.86
0.065.45 5.12 5.94
sdc 0.00 0.00 15.80 0.00 738.20 0.0046.72
0.085.22 4.76 7.52
sdd 0.00 0.00 10.80 0.00 728.40 0.0067.44
0.065.81 5.48 5.92
sde 0.00 0.00 11.60 2.00 377.60 1027.20 103.29
0.075.18 4.75 6.46
sdf 0.00 0.00 14.60 0.00 473.60 0.0032.44
0.095.90 5.78 8.44
sdg 0.00 0.00 87.00 0.00 37454.80 0.00 430.51
0.374.26 0.82 7.12
sdb 0.00 0.00 15.80 0.00 786.40 0.0049.77
0.106.56 5.76 9.10
sdc 0.00 0.00 10.20 1.60 217.60 911.2095.66
0.064.93 4.51 5.32
sdd 0.00 0.00 13.00 0.00 665.00 0.0051.15
0.086.12 5.80 7.54
sde 0.00 0.00 11.60 0.00 419.40 0.0036.16
0.065.43 5.17 6.00
sdf 0.00 0.00 11.00 1.40 315.00 826.8092.08
0.075.27 4.89 6.06
sdg 0.00 0.00 27.00 0.00 8629.60 0.00 319.61
0.020.87 0.37 1.00
sdb 0.00 0.00 12.80 0.00 380.00 0.0029.69
0.075.22 4.98 6.38
sdc 0.00 0.00 14.80 0.00 495.80 0.0033.50
0.085.39 5.19 7.68
sdd 0.00 0.00 10.40 0.00 267.40 0.0025.71
0.065.87 5.46 5.68
sde 0.00 0.00 12.20 0.00 691.20 0.0056.66
0.075.93 5.48 6.68
sdf 0.00 0.00 11.80 0.00 544.40 0.0046.14
0.075.83 5.63 6.64
sdg 0.00 0.00 57.00 0.00 22033.00 0.00 386.54
0.061.07 0.38 2.16
sdb 0.00 0.00 13.20 0.00 546.40 0.0041.39
0.085.73 5.73 7.56
sdc 0.00 0.00 14.00 0.00 583.60 0.0041.69
0.085.57 5.34 7.48
sdd 0.00 0.00 12.80 0.00 639.20 0.0049.94
0.075.61 5.14 6.58
sde 0.00 0.00 12.40 0.00 403.20 0.0032.52
0.26 20.98 11.03 13.68
sdf 0.00 0.00 15.00 0.00 475.80 0.0031.72
0.095.71 5.37 8.06
sdg 0.00 0.00 91.80 0.00 39239.00 0.00 427.44
0.576.24 0.76 6.94
sdb 0.00 0.00 10.60 0.00 326.60 0.0030.81
0.065.60 5.04 5.34
sdc 0.00 0.00 12.80 0.00 644.40 0.0050.34
0.075.72 5.27 6.74
sdd 0.00 0.00 14.80 0.00 624.00 0.0042.16
0.085.61 5.50 8.14
sde 0.00 0.00 9.20 0.00 283.00 0.0030.76
0.055.83 5.67 5.22
sdf 0.00 0.00 13.40 0.00 578.00 0.0043.13
0.075.39 5.15 6.90
sdg 0.00 0.00 12.80
