[jira] [Created] (TS-1598) Coring in SSL
Abhishek Nayani created TS-1598: --- Summary: Coring in SSL Key: TS-1598 URL: https://issues.apache.org/jira/browse/TS-1598 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Environment: RHEL6.2 64bit Reporter: Abhishek Nayani Fix For: 3.2.0 (gdb) bt #0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6 #1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10 #2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10 #3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out, vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at SSLNetVConnection.cc:135 #4 0x0066f3b0 in SSLNetVConnection::net_read_io (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at SSLNetVConnection.cc:288 #5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, event=value optimized out, e=value optimized out) at UnixNet.cc:381 #6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at I_Continuation.h:146 #7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at UnixEThread.cc:142 #8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at UnixEThread.cc:264 #9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0 #11 0x00390ace76dd in clone () from /lib64/libc.so.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504640#comment-13504640 ] Leif Hedstrom commented on TS-1595: --- I guess since the core the plumbing is in place, adding support for @config=value would be reasonable. I can look into that later today, but I doubt performance will be very noticeable compared to the plugin (but, easier to use, when you only want to override one or a couple configs). different domain have different origin_max_connections? --- Key: TS-1595 URL: https://issues.apache.org/jira/browse/TS-1595 Project: Traffic Server Issue Type: Sub-task Components: Network Reporter: Bin Chen Assignee: Bin Chen Priority: Minor In our env, we want different domain having different origin_max_connections to manage connection more careful avoiding network throttling. If not have different config in remap, use origin_max_connections default. Other, config in remap will replace origin_max_connections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504705#comment-13504705 ] Leif Hedstrom commented on TS-1595: --- Oh, and I meant the remap config plugin, not the Lua plugin. I'm sure the Lua plugin will be plenty fast, but the C plugin is probably faster :) I'm thinking about this some more, it's possible we could / should add a Overridable class member to the remap structure. This would allow for each remap rule to carry one of these as well. I can look into this, unless you really want to work on it :). Just let me know. different domain have different origin_max_connections? --- Key: TS-1595 URL: https://issues.apache.org/jira/browse/TS-1595 Project: Traffic Server Issue Type: Sub-task Components: Network Reporter: Bin Chen Assignee: Bin Chen Priority: Minor In our env, we want different domain having different origin_max_connections to manage connection more careful avoiding network throttling. If not have different config in remap, use origin_max_connections default. Other, config in remap will replace origin_max_connections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1598) Coring in SSL
[ https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504806#comment-13504806 ] James Peach commented on TS-1598: - Without more info, I don't think there's anything we can do here. Is this reproducible? Can you get a packet trace or verbose log? Coring in SSL - Key: TS-1598 URL: https://issues.apache.org/jira/browse/TS-1598 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Environment: RHEL6.2 64bit Reporter: Abhishek Nayani Fix For: 3.2.0 (gdb) bt #0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6 #1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10 #2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10 #3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out, vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at SSLNetVConnection.cc:135 #4 0x0066f3b0 in SSLNetVConnection::net_read_io (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at SSLNetVConnection.cc:288 #5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, event=value optimized out, e=value optimized out) at UnixNet.cc:381 #6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at I_Continuation.h:146 #7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at UnixEThread.cc:142 #8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at UnixEThread.cc:264 #9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0 #11 0x00390ace76dd in clone () from /lib64/libc.so.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1598) Coring in SSL
[ https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1598: -- Fix Version/s: (was: 3.2.0) Coring in SSL - Key: TS-1598 URL: https://issues.apache.org/jira/browse/TS-1598 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Environment: RHEL6.2 64bit Reporter: Abhishek Nayani (gdb) bt #0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6 #1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10 #2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10 #3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out, vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at SSLNetVConnection.cc:135 #4 0x0066f3b0 in SSLNetVConnection::net_read_io (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at SSLNetVConnection.cc:288 #5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, event=value optimized out, e=value optimized out) at UnixNet.cc:381 #6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at I_Continuation.h:146 #7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at UnixEThread.cc:142 #8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at UnixEThread.cc:264 #9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0 #11 0x00390ace76dd in clone () from /lib64/libc.so.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1595) different domain have different origin_max_connections?
[ https://issues.apache.org/jira/browse/TS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505081#comment-13505081 ] Bin Chen commented on TS-1595: -- TS-1595 is only one requirement. I think ts should have unified UI (Overridable config, more flexable ACL support, more friendly plugin param about every remap rule, cache-control ). So user only take care of the unidfied UI in remap.config. different domain have different origin_max_connections? --- Key: TS-1595 URL: https://issues.apache.org/jira/browse/TS-1595 Project: Traffic Server Issue Type: Sub-task Components: Network Reporter: Bin Chen Assignee: Bin Chen Priority: Minor In our env, we want different domain having different origin_max_connections to manage connection more careful avoiding network throttling. If not have different config in remap, use origin_max_connections default. Other, config in remap will replace origin_max_connections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1598) Coring in SSL
[ https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505195#comment-13505195 ] Abhishek Nayani commented on TS-1598: - This happens once or twice a day. I do not have particular request which can reproduce this. The traffic is predominantly WebDAV (CalDAV) over SSL. Let me know if you need any other info. I've a core but cannot attach it to this bug as it is 3GB. Coring in SSL - Key: TS-1598 URL: https://issues.apache.org/jira/browse/TS-1598 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Environment: RHEL6.2 64bit Reporter: Abhishek Nayani (gdb) bt #0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6 #1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10 #2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10 #3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out, vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at SSLNetVConnection.cc:135 #4 0x0066f3b0 in SSLNetVConnection::net_read_io (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at SSLNetVConnection.cc:288 #5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, event=value optimized out, e=value optimized out) at UnixNet.cc:381 #6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at I_Continuation.h:146 #7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at UnixEThread.cc:142 #8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at UnixEThread.cc:264 #9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0 #11 0x00390ace76dd in clone () from /lib64/libc.so.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1594) ProxyMutexPtr and PtrProxyMutex are identical
[ https://issues.apache.org/jira/browse/TS-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1594. - Resolution: Fixed 4704d3a5a9584e9c98e657a4dde1f0d3c973bf10 TS-1594: ProxyMutexPtr and PtrProxyMutex are identical ProxyMutexPtr and PtrProxyMutex are identical --- Key: TS-1594 URL: https://issues.apache.org/jira/browse/TS-1594 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.3.0 Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.3.1 ProxyMutexPtr and PtrProxyMutex are identical; half the code uses one flavour and half the code uses the other. Let's remove ProxyMutexPtr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1506) %cquuh log symbol will crash TS when requesting a SSL url.
[
https://issues.apache.org/jira/browse/TS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Conan Wang updated TS-1506:
---
Attachment: TS-1506.patch
Can not reproduce the crash on git master, but the output is still not correct.
Attached patch make 'cquuh' and 'cquup' work if request is valid.
%cquuh log symbol will crash TS when requesting a SSL url.
Key: TS-1506
URL: https://issues.apache.org/jira/browse/TS-1506
Project: Traffic Server
Issue Type: Bug
Components: Logging, SSL
Affects Versions: 3.2.3
Environment: OS X 10.8
Reporter: Conan Wang
Fix For: 3.3.3
Attachments: TS-1506.patch
cquuh (or cquuc, cquup) field symbol for logs_xml.config is introduced in
https://issues.apache.org/jira/browse/TS-1002. Requesting a normal url is OK.
If request a HTTPS url, TS will crash.
If log format contains %cquuh, TS will crash at logging phase.
{code}
[Sep 27 18:00:46.714] Server {0x103c04000} NOTE: cache enabled
[Sep 27 18:00:54.077] Server {0x108c06000} DEBUG: (ssl)
[SSLNextProtocolAccept:mainEvent] event 202 netvc 0x102065710
[Sep 27 18:00:54.078] Server {0x108c06000} DEBUG: (ssl) ssl=0x10470c240
ad=112 lookup=0x1007af780 server=wkl.me
[Sep 27 18:00:54.078] Server {0x108c06000} DEBUG: (ssl) found SSL context
0x101318fc0 for requested name 'wkl.me'
[Sep 27 18:00:54.078] Server {0x108c06000} DEBUG: (ssl) advertised NPN
sethttp/1.http/1.0
[Sep 27 18:00:54.082] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
[Sep 27 18:00:54.082] Server {0x108c06000} DEBUG: (ssl) client selected next
protocol http/1.1
[Sep 27 18:00:54.082] Server {0x108c06000} DEBUG: (ssl)
[SSLNextProtocolAccept:mainEvent] event 102 netvc 0x102065710
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK(read)
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read == 0
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl) read_from_net, read
finished - would block
[Sep 27 18:00:54.114] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[Sep 27 18:00:54.114] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=657
SSL Read
GET / HTTP/1.1
Host: wkl.me
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.4
(KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: __utma=113004674.1646024061.1302082154.1348645626.1348738067.49;
__utmb=113004674.99.10.1348738067; __utmc=113004674;
__utmz=113004674.1319557793.26.11.utmcsr=about.me|utmccn=(referral)|utmcmd=referral|utmcct=/wkl
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK(read)
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read=657
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=3439
[Sep 27 18:00:54.131] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[Sep 27 18:00:54.131] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK(read)
[Sep 27 18:00:54.131] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read == 0
[Sep 27 18:00:54.133] Server {0x108c06000} DEBUG: (ssl) read_from_net, read
finished - would block
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite, before do_SSL_write, l=302,
towrite=1061, b=0x103095340
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite,Number of bytes written=302 ,
total=302
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite, before do_SSL_write, l=759,
towrite=1061, b=0x103095300
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite,Number of bytes written=759 ,
total=1061
[Sep 27
[jira] [Commented] (TS-1506) %cquuh log symbol will crash TS when requesting a SSL url.
[
https://issues.apache.org/jira/browse/TS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505206#comment-13505206
]
Conan Wang commented on TS-1506:
As for invalid https requests (like handshake fail, not match a certificate),
the log line which contain 'cquuh' is not perfect: other fields may output
strange characters. Need further check.
%cquuh log symbol will crash TS when requesting a SSL url.
Key: TS-1506
URL: https://issues.apache.org/jira/browse/TS-1506
Project: Traffic Server
Issue Type: Bug
Components: Logging, SSL
Affects Versions: 3.2.3
Environment: OS X 10.8
Reporter: Conan Wang
Fix For: 3.3.3
Attachments: TS-1506.patch
cquuh (or cquuc, cquup) field symbol for logs_xml.config is introduced in
https://issues.apache.org/jira/browse/TS-1002. Requesting a normal url is OK.
If request a HTTPS url, TS will crash.
If log format contains %cquuh, TS will crash at logging phase.
{code}
[Sep 27 18:00:46.714] Server {0x103c04000} NOTE: cache enabled
[Sep 27 18:00:54.077] Server {0x108c06000} DEBUG: (ssl)
[SSLNextProtocolAccept:mainEvent] event 202 netvc 0x102065710
[Sep 27 18:00:54.078] Server {0x108c06000} DEBUG: (ssl) ssl=0x10470c240
ad=112 lookup=0x1007af780 server=wkl.me
[Sep 27 18:00:54.078] Server {0x108c06000} DEBUG: (ssl) found SSL context
0x101318fc0 for requested name 'wkl.me'
[Sep 27 18:00:54.078] Server {0x108c06000} DEBUG: (ssl) advertised NPN
sethttp/1.http/1.0
[Sep 27 18:00:54.082] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
[Sep 27 18:00:54.082] Server {0x108c06000} DEBUG: (ssl) client selected next
protocol http/1.1
[Sep 27 18:00:54.082] Server {0x108c06000} DEBUG: (ssl)
[SSLNextProtocolAccept:mainEvent] event 102 netvc 0x102065710
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK(read)
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read == 0
[Sep 27 18:00:54.099] Server {0x108c06000} DEBUG: (ssl) read_from_net, read
finished - would block
[Sep 27 18:00:54.114] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[Sep 27 18:00:54.114] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=657
SSL Read
GET / HTTP/1.1
Host: wkl.me
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.4
(KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: __utma=113004674.1646024061.1302082154.1348645626.1348738067.49;
__utmb=113004674.99.10.1348738067; __utmc=113004674;
__utmz=113004674.1319557793.26.11.utmcsr=about.me|utmccn=(referral)|utmcmd=referral|utmcct=/wkl
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK(read)
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read=657
[Sep 27 18:00:54.115] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=3439
[Sep 27 18:00:54.131] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[Sep 27 18:00:54.131] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK(read)
[Sep 27 18:00:54.131] Server {0x108c06000} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read == 0
[Sep 27 18:00:54.133] Server {0x108c06000} DEBUG: (ssl) read_from_net, read
finished - would block
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite, before do_SSL_write, l=302,
towrite=1061, b=0x103095340
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite,Number of bytes written=302 ,
total=302
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
SSLNetVConnection::loadBufferAndCallWrite, before do_SSL_write, l=759,
towrite=1061, b=0x103095300
[Sep 27 18:00:54.351] Server {0x108c06000} DEBUG: (ssl)
[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505218#comment-13505218
]
samahee commented on TS-1006:
-
it it fixed?
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.2
Attachments: memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
18350080 |1153024 | 2048 | memory/hdrHeap
53248 | 2912 |208 |
memory/httpCacheAltAllocator
0 | 0 |112 |
memory/OneWayTunnelAllocator
157696 | 1232 | 1232 |
memory/hostDBContAllocator
102240 |
[jira] [Commented] (TS-1598) Coring in SSL
[ https://issues.apache.org/jira/browse/TS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505219#comment-13505219 ] James Peach commented on TS-1598: - ATS is calling: int rres = SSL_read(sslvc-ssl, b-end() + offset, (int)block_write_avail); And we end up here in OpenSSL: int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek) ... if ((unsigned int)len rr-length) n = rr-length; else n = (unsigned int)len; memcpy(buf,(rr-data[rr-off]),n); So I'd guess that we screwed up IO buffer management somehow, or there's a OpenSSL bug that is screwing up the memcpy. Abhishek, what verion of OpenSSL are you using? Since you have a core, can you try to get the valued of buf, len and n from ssl3_read_bytes? Coring in SSL - Key: TS-1598 URL: https://issues.apache.org/jira/browse/TS-1598 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Environment: RHEL6.2 64bit Reporter: Abhishek Nayani (gdb) bt #0 0x00390ac88c5b in memcpy () from /lib64/libc.so.6 #1 0x003f962264ce in ssl3_read_bytes () from /usr/lib64/libssl.so.10 #2 0x003f9670 in ?? () from /usr/lib64/libssl.so.10 #3 0x0066eaf7 in ssl_read_from_net (nh=value optimized out, vc=0x2ada4437e0a0, lthread=0x2ada11ff2010, ret=@0x2ada174e5c10) at SSLNetVConnection.cc:135 #4 0x0066f3b0 in SSLNetVConnection::net_read_io (this=0x2ada4437e0a0, nh=0x2ada11ff51e8, lthread=0x2ada11ff2010) at SSLNetVConnection.cc:288 #5 0x00676fb2 in NetHandler::mainNetEvent (this=0x2ada11ff51e8, event=value optimized out, e=value optimized out) at UnixNet.cc:381 #6 0x006a0ba4 in handleEvent (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at I_Continuation.h:146 #7 EThread::process_event (this=0x2ada11ff2010, e=0x24fdfc0, calling_code=5) at UnixEThread.cc:142 #8 0x006a16f3 in EThread::execute (this=0x2ada11ff2010) at UnixEThread.cc:264 #9 0x0069fae2 in spawn_thread_internal (a=0x268f1a0) at Thread.cc:88 #10 0x00390b007851 in start_thread () from /lib64/libpthread.so.0 #11 0x00390ace76dd in clone () from /lib64/libc.so.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
[
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505224#comment-13505224
]
James Peach commented on TS-1528:
-
Jack, any update?
ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
---
Key: TS-1528
URL: https://issues.apache.org/jira/browse/TS-1528
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Debian testing (wheezy) on i686
Reporter: Jack Bates
Assignee: James Peach
Fix For: 3.3.3
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it, too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What details can I provide to help debug this? James Peach suggested
attaching some kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1500) ssl_multicert.config specify sslcert per port
[ https://issues.apache.org/jira/browse/TS-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1500: --- Assignee: James Peach ssl_multicert.config specify sslcert per port - Key: TS-1500 URL: https://issues.apache.org/jira/browse/TS-1500 Project: Traffic Server Issue Type: Improvement Components: SSL Affects Versions: 3.2.0 Reporter: Kris Lindgren Assignee: James Peach Fix For: 3.3.3 Trying to configure ssl termination on traffic server on a per-port basis(would really like to have per ip/port). An example of what I am wanting to do is: Inet - LB ( 1.1.1.1:443 ) - ATS ( 10.1.0.3:443 ) - web (10.0.0.2:80 ) Inet - LB ( 1.1.1.2:443 ) - ATS ( 10.1.0.3:444 ) - web (10.0.0.3:80 ) Inet - LB ( 1.1.1.3:443 ) - ATS ( 10.1.0.3:445 ) - web (10.0.0.4:80 ) Where in ATS I would then have a config like: dest_ip=10.1.0.3:443ssl_cert_name=one.crt ssl_key_name=one.key dest_ip=10.1.0.3:444ssl_cert_name=two.crt ssl_key_name=two.key dest_ip=10.1.0.3:445ssl_cert_name=three.crt ssl_key_name=three.key This way a unique IP is terminated on the LB and the LB just balances a different port on ATS, which handles the ssl termination. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505249#comment-13505249
]
Zhao Yongming commented on TS-1006:
---
not yet, we are still working on another solution, hopes we can submit for
review in next week or soon.
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Bin Chen
Fix For: 3.3.2
Attachments: memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
18350080 |1153024 | 2048 | memory/hdrHeap
53248 | 2912 |208 |
memory/httpCacheAltAllocator
0 | 0 |112 |
memory/OneWayTunnelAllocator
157696 |
[jira] [Created] (TS-1599) set OpenSSL allocator with CRYPTO_set_mem_functions
James Peach created TS-1599: --- Summary: set OpenSSL allocator with CRYPTO_set_mem_functions Key: TS-1599 URL: https://issues.apache.org/jira/browse/TS-1599 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Priority: Minor We should use CRYPTO_set_mem_functions() or one of the related APIs to force OpenSSL to use the allocator that ATS is using. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1600) when one http transaction complete, should HttpClientSession release serversession
Bin Chen created TS-1600: Summary: when one http transaction complete, should HttpClientSession release serversession Key: TS-1600 URL: https://issues.apache.org/jira/browse/TS-1600 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Priority: Minor when one http transaction complete, HttpClientSession store last serversession in bound_ss. In high hit ratio, ts may use more serversession using less lock(server session pool). But in high pressure env, ts will use more serversession. Maybe we should use less serversession(origin connection limitted) by release bound_ss to serversession pool in transaction complete(HttpClientSession::release()) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
