[jira] [Commented] (TS-2113) balancer plugin is in the source tree but does not build
[
https://issues.apache.org/jira/browse/TS-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874710#comment-13874710
]
Thomas Berger commented on TS-2113:
---
It builds on trunk for me. I would assume: yes
balancer plugin is in the source tree but does not build
Key: TS-2113
URL: https://issues.apache.org/jira/browse/TS-2113
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 4.2.0
The balancer plugin is currently in our experimental plugin tree, but doesn't
build even with {{--enable-experimental}}.
This should be fixed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2480) Choose the ip related SSL_CTX not the default when creating new ssl
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874730#comment-13874730 ] Wei Sun commented on TS-2480: - Yes, it is related to the order of callbacks invoked by openssl. If the client presents a non-empty ticket, session ticket callback is invoked prior to SNI callback. Otherwise, the order is in reverse. It's a problem if the serverName extension causes a new SSL context to be selected, and I'm wondering is there a good reason to tolerate the following case: dest_ip=x.x.x.1 ssl_cert_name=server1.pem // include alternate name1 dest_ip=x.x.x.2 ssl_cert_name=server2.pem // include alternate name2 A client connects to x.x.x.1 and presents ServerName ext: 'name2'. I'd like to make a simple fix for the session ticket case in the short run, recreated a patch in the attachment. I can update it if TS-2031 is a need in here. Choose the ip related SSL_CTX not the default when creating new ssl Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2480) Choose the ip related SSL_CTX not the default when creating new ssl
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2480: Attachment: TS-2480.diff Choose the ip related SSL_CTX not the default when creating new ssl Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2480) Choose the ip related SSL_CTX not the default when creating new ssl
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2480: Attachment: (was: TS2480.diff) Choose the ip related SSL_CTX not the default when creating new ssl Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2480: Summary: Choose the address related SSL_CTX for session ticket callback (was: Choose the ip related SSL_CTX not the default when creating new ssl ) Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874730#comment-13874730 ] Wei Sun edited comment on TS-2480 at 1/17/14 12:51 PM: --- Yes, it is related to the order of callbacks invoked by openssl. If the client presents a non-empty ticket, session ticket callback is invoked prior to SNI callback. Otherwise, the order is in reverse. It's a problem if the serverName extension causes a new SSL context to be selected, and I'm wondering is there a good reason to tolerate the following case: dest_ip=x.x.x.1 ssl_cert_name=server1.pem // include alternate name1 dest_ip=x.x.x.2 ssl_cert_name=server2.pem // include alternate name2 A client connects to x.x.x.1 and presents ServerName ext: 'name2'. I'd like to change it as a simple fix for the session ticket case in the short run, recreated a patch in the attachment. I can update it if TS-2031 is a need in here. was (Author: sunwei): Yes, it is related to the order of callbacks invoked by openssl. If the client presents a non-empty ticket, session ticket callback is invoked prior to SNI callback. Otherwise, the order is in reverse. It's a problem if the serverName extension causes a new SSL context to be selected, and I'm wondering is there a good reason to tolerate the following case: dest_ip=x.x.x.1 ssl_cert_name=server1.pem // include alternate name1 dest_ip=x.x.x.2 ssl_cert_name=server2.pem // include alternate name2 A client connects to x.x.x.1 and presents ServerName ext: 'name2'. I'd like to make a simple fix for the session ticket case in the short run, recreated a patch in the attachment. I can update it if TS-2031 is a need in here. Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2480: Attachment: TS-2480.diff Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2480.diff, TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2480: Attachment: (was: TS-2480.diff) Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Wish Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 4.2.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874813#comment-13874813 ] Thomas Berger commented on TS-2307: --- According to [RFC2515|http://www.ietf.org/rfc/rfc2616.txt], Section 3.11, the ETAG need's quotes. So i would suggest this is a bug of the origin server. Range request with If-Range does not work - Key: TS-2307 URL: https://issues.apache.org/jira/browse/TS-2307 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.5, 4.0.1, 4.0.2 Reporter: Jungwoo Lee Labels: A Fix For: 4.2.0 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings -- Delete the cache of Chrome -- Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) -- if (!if_value || if_value[0] == '' || (comma_sep_list_len 1 if_value[1] == '/')) --- when ETAG doesn't start and end with this condition will be failed. -- The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. -- When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1702) enable_read_while_writer on with simultaneous cache entry refreshes can leak 304's to client
[ https://issues.apache.org/jira/browse/TS-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell resolved TS-1702. -- Resolution: Fixed Fix Version/s: (was: 5.0.0) 4.1.2 The fix to TS-1086 seems to fix this, and is the same underlying issue. enable_read_while_writer on with simultaneous cache entry refreshes can leak 304's to client Key: TS-1702 URL: https://issues.apache.org/jira/browse/TS-1702 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4, 3.2.0 Reporter: William Bardwell Labels: A Fix For: 4.1.2 enable_read_while_writer will sometimes fail to get the sort of locks that it wants, and will try to send a request forward that is not conditional, but if the cache entry content has an ETag and Last-Modified-Time header, then the code in HttpTransact::handle_cache_write_lock(State* s) to handle a failed write lock will remove the If-Modified-Since but not the If-None-Match. It should remove both. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2113) balancer plugin is in the source tree but does not build
[
https://issues.apache.org/jira/browse/TS-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2113.
---
Resolution: Fixed
Cool, thanks! Resolving.
balancer plugin is in the source tree but does not build
Key: TS-2113
URL: https://issues.apache.org/jira/browse/TS-2113
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 4.2.0
The balancer plugin is currently in our experimental plugin tree, but doesn't
build even with {{--enable-experimental}}.
This should be fixed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2505) Add command line to disable cache storage device
[ https://issues.apache.org/jira/browse/TS-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2505: --- Assignee: Alan M. Carroll Add command line to disable cache storage device Key: TS-2505 URL: https://issues.apache.org/jira/browse/TS-2505 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll For larger installations it can be very useful to be able to mark a disk drive as failed before ATS detects that on its own. At some point in the future a matching ability to bring a drive back online should be added. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874892#comment-13874892
]
Leif Hedstrom commented on TS-1547:
---
[~bettydreamit] The patch is up there in the attachments. Can you try it ?
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 5.0.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2505) Add command line to disable cache storage device
[ https://issues.apache.org/jira/browse/TS-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2505: Priority: Minor (was: Major) Fix Version/s: 4.1.3 Add command line to disable cache storage device Key: TS-2505 URL: https://issues.apache.org/jira/browse/TS-2505 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 4.1.3 For larger installations it can be very useful to be able to mark a disk drive as failed before ATS detects that on its own. At some point in the future a matching ability to bring a drive back online should be added. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874895#comment-13874895
]
Leif Hedstrom commented on TS-1666:
---
William: This is still ongoing ?
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Priority: Critical
Labels: Crash
Fix For: 4.2.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-1545) possible crash in records stat snap
[
https://issues.apache.org/jira/browse/TS-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1545:
--
Fix Version/s: (was: 6.0.0)
4.2.0
possible crash in records stat snap
---
Key: TS-1545
URL: https://issues.apache.org/jira/browse/TS-1545
Project: Traffic Server
Issue Type: Bug
Components: Core, Stats
Affects Versions: 3.3.0
Environment: debug build, long time regression testing
Reporter: Zhao Yongming
Labels: Crash
Fix For: 4.2.0
Attachments: records.snap, stats.snap
when I running regression testing in the loop script, we come to fail to
start the server. well, the codes may handle the issue when we build without
--enable-debug, but that looks like we have something may break records snap.
open this issue in case someone need it.
{code}
[TrafficServer] using root directory '/opt/ats'
FATAL: RecMessage.cc:426: failed assert `eh-magic == REC_MESSAGE_ELE_MAGIC`
/opt/ats/bin/traffic_server - STACK TRACE:
/opt/ats/lib/libtsutil.so.3(ink_fatal_die+0x0)[0x77baeca1]
/opt/ats/lib/libtsutil.so.3(_Z12ink_get_randv+0x0)[0x77badbb8]
/opt/ats/bin/traffic_server(_Z23RecMessageUnmarshalNextP13RecMessageHdrP13RecMessageItrPP9RecRecord+0xbf)[0x6ed860]
/opt/ats/bin/traffic_server(_Z16RecReadStatsFilev+0xc1)[0x6e5e36]
/opt/ats/bin/traffic_server(_Z11RecCoreInit8RecModeTP5Diags+0xec)[0x6e254b]
/opt/ats/bin/traffic_server(_Z14RecProcessInit8RecModeTP5Diags+0x3b)[0x6e7769]
/opt/ats/bin/traffic_server[0x51d4a5]
/opt/ats/bin/traffic_server(main+0x1df)[0x51ee39]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7515b60d]
/opt/ats/bin/traffic_server[0x4d8f99]
Program received signal SIGABRT, Aborted.
0x7516ec15 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x7516ec15 in raise () from /lib64/libc.so.6
#1 0x7517008b in abort () from /lib64/libc.so.6
#2 0x77baeb2c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77baebfe in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`,
ap=0x7fffc8b8) at ink_error.cc:65
#4 0x77baeca1 in ink_fatal (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x77badbb8 in _ink_assert (expression=0x76ffa0 eh-magic ==
REC_MESSAGE_ELE_MAGIC, file=0x76fe40 RecMessage.cc, line=426)
at ink_assert.cc:38
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
#8 0x006e254b in RecCoreInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecCore.cc:209
#9 0x006e7769 in RecProcessInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecProcess.cc:313
#10 0x0051d4a5 in initialize_process_manager () at Main.cc:413
#11 0x0051ee39 in main (argc=1, argv=0x7fffdd08) at Main.cc:1409
(gdb) f 6
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
(gdb) l
421 itr-ele_hdr = (RecMessageEleHdr *) ((char *) (msg) +
itr-ele_hdr-o_next);
422 itr-next += 1;
423 eh = itr-ele_hdr;
424 }
425
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
427
428 // If the file is corrupt, ignore the the rest of the file.
429 if (eh-magic != REC_MESSAGE_ELE_MAGIC) {
430 Warning(Persistent statistics file records.stat is corrupted.
Ignoring the rest of the file\n);
(gdb) p eh-magic
$1 = 0
(gdb) p REC_MESSAGE_ELE_MAGIC
$2 = 4027445261
(gdb) p eh
$3 = (RecMessageEleHdr *) 0xff4138
(gdb) p *eh
$4 = {magic = 0, o_next = 0}
(gdb) f 7
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
(gdb) l
564 if (RecMessageUnmarshalFirst(m, itr, r) != REC_ERR_FAIL) {
565 do {
566 if ((r-name == NULL) || (!strlen(r-name)))
567 continue;
568 RecSetRecord(r-rec_type, r-name, r-data_type, (r-data),
(r-stat_meta.data_raw), false);
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
570 }
571 }
572
573 ink_rwlock_unlock(g_records_rwlock);
(gdb) p r
$5 = (RecRecord *) 0xff4070
(gdb) p *r
$6 = {rec_type = RECT_PROCESS, name = 0xff4118 , data_type = RECD_INT, data
= {rec_int = 0, rec_float = 0, rec_string = 0x0,
rec_counter = 0}, data_default = {rec_int = 0, rec_float = 0, rec_string
= 0x0, rec_counter = 0}, lock =
[jira] [Commented] (TS-1545) possible crash in records stat snap
[
https://issues.apache.org/jira/browse/TS-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874896#comment-13874896
]
Leif Hedstrom commented on TS-1545:
---
What do we think here? Would it be worthwhile trying to detect this, and nuke
the .snap files ?
possible crash in records stat snap
---
Key: TS-1545
URL: https://issues.apache.org/jira/browse/TS-1545
Project: Traffic Server
Issue Type: Bug
Components: Core, Stats
Affects Versions: 3.3.0
Environment: debug build, long time regression testing
Reporter: Zhao Yongming
Labels: Crash
Fix For: 4.2.0
Attachments: records.snap, stats.snap
when I running regression testing in the loop script, we come to fail to
start the server. well, the codes may handle the issue when we build without
--enable-debug, but that looks like we have something may break records snap.
open this issue in case someone need it.
{code}
[TrafficServer] using root directory '/opt/ats'
FATAL: RecMessage.cc:426: failed assert `eh-magic == REC_MESSAGE_ELE_MAGIC`
/opt/ats/bin/traffic_server - STACK TRACE:
/opt/ats/lib/libtsutil.so.3(ink_fatal_die+0x0)[0x77baeca1]
/opt/ats/lib/libtsutil.so.3(_Z12ink_get_randv+0x0)[0x77badbb8]
/opt/ats/bin/traffic_server(_Z23RecMessageUnmarshalNextP13RecMessageHdrP13RecMessageItrPP9RecRecord+0xbf)[0x6ed860]
/opt/ats/bin/traffic_server(_Z16RecReadStatsFilev+0xc1)[0x6e5e36]
/opt/ats/bin/traffic_server(_Z11RecCoreInit8RecModeTP5Diags+0xec)[0x6e254b]
/opt/ats/bin/traffic_server(_Z14RecProcessInit8RecModeTP5Diags+0x3b)[0x6e7769]
/opt/ats/bin/traffic_server[0x51d4a5]
/opt/ats/bin/traffic_server(main+0x1df)[0x51ee39]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7515b60d]
/opt/ats/bin/traffic_server[0x4d8f99]
Program received signal SIGABRT, Aborted.
0x7516ec15 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x7516ec15 in raise () from /lib64/libc.so.6
#1 0x7517008b in abort () from /lib64/libc.so.6
#2 0x77baeb2c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77baebfe in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`,
ap=0x7fffc8b8) at ink_error.cc:65
#4 0x77baeca1 in ink_fatal (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x77badbb8 in _ink_assert (expression=0x76ffa0 eh-magic ==
REC_MESSAGE_ELE_MAGIC, file=0x76fe40 RecMessage.cc, line=426)
at ink_assert.cc:38
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
#8 0x006e254b in RecCoreInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecCore.cc:209
#9 0x006e7769 in RecProcessInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecProcess.cc:313
#10 0x0051d4a5 in initialize_process_manager () at Main.cc:413
#11 0x0051ee39 in main (argc=1, argv=0x7fffdd08) at Main.cc:1409
(gdb) f 6
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
(gdb) l
421 itr-ele_hdr = (RecMessageEleHdr *) ((char *) (msg) +
itr-ele_hdr-o_next);
422 itr-next += 1;
423 eh = itr-ele_hdr;
424 }
425
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
427
428 // If the file is corrupt, ignore the the rest of the file.
429 if (eh-magic != REC_MESSAGE_ELE_MAGIC) {
430 Warning(Persistent statistics file records.stat is corrupted.
Ignoring the rest of the file\n);
(gdb) p eh-magic
$1 = 0
(gdb) p REC_MESSAGE_ELE_MAGIC
$2 = 4027445261
(gdb) p eh
$3 = (RecMessageEleHdr *) 0xff4138
(gdb) p *eh
$4 = {magic = 0, o_next = 0}
(gdb) f 7
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
(gdb) l
564 if (RecMessageUnmarshalFirst(m, itr, r) != REC_ERR_FAIL) {
565 do {
566 if ((r-name == NULL) || (!strlen(r-name)))
567 continue;
568 RecSetRecord(r-rec_type, r-name, r-data_type, (r-data),
(r-stat_meta.data_raw), false);
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
570 }
571 }
572
573 ink_rwlock_unlock(g_records_rwlock);
(gdb) p r
$5 = (RecRecord *) 0xff4070
(gdb) p *r
$6 = {rec_type = RECT_PROCESS, name = 0xff4118 , data_type = RECD_INT, data
= {rec_int = 0, rec_float = 0, rec_string = 0x0,
rec_counter = 0},
[jira] [Created] (TS-2505) Add command line to disable cache storage device
Alan M. Carroll created TS-2505: --- Summary: Add command line to disable cache storage device Key: TS-2505 URL: https://issues.apache.org/jira/browse/TS-2505 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll For larger installations it can be very useful to be able to mark a disk drive as failed before ATS detects that on its own. At some point in the future a matching ability to bring a drive back online should be added. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874897#comment-13874897
]
William Bardwell commented on TS-1547:
--
The attachment is bettydramit's patch...I haven't gotten legal clearance to
send out my patch, but my textual description implies the couple lines needed
for my approach...
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 5.0.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874899#comment-13874899
]
William Bardwell commented on TS-1666:
--
I haven't seen it in a while, but I think that is more a failure to do the
right sort of testing, because I have not updated or fixed anything related to
this.
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Priority: Critical
Labels: Crash
Fix For: 4.2.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2505) Add command line to disable cache storage device
[
https://issues.apache.org/jira/browse/TS-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2505:
Description:
For larger installations it can be very useful to be able to mark a disk drive
as failed before ATS detects that on its own.
At some point in the future a matching ability to bring a drive back online
should be added.
Usage:
{{traffic_line --offline}} _path_
where _path_ is a path used in {{storage.config}}
was:
For larger installations it can be very useful to be able to mark a disk drive
as failed before ATS detects that on its own.
At some point in the future a matching ability to bring a drive back online
should be added.
Add command line to disable cache storage device
Key: TS-2505
URL: https://issues.apache.org/jira/browse/TS-2505
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 4.1.3
For larger installations it can be very useful to be able to mark a disk
drive as failed before ATS detects that on its own.
At some point in the future a matching ability to bring a drive back online
should be added.
Usage:
{{traffic_line --offline}} _path_
where _path_ is a path used in {{storage.config}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1545) possible crash in records stat snap
[
https://issues.apache.org/jira/browse/TS-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874904#comment-13874904
]
William Bardwell commented on TS-1545:
--
I think so, it can leave a machine in a loop where it won't work at all without
deleting those files. The current code would need a lot more validation of the
data that is being read in. Maybe it needs fancier marshalling out so you can
just tell that a file was partially written. (Magic number that is written
last, or something similar.)
possible crash in records stat snap
---
Key: TS-1545
URL: https://issues.apache.org/jira/browse/TS-1545
Project: Traffic Server
Issue Type: Bug
Components: Core, Stats
Affects Versions: 3.3.0
Environment: debug build, long time regression testing
Reporter: Zhao Yongming
Labels: Crash
Fix For: 4.2.0
Attachments: records.snap, stats.snap
when I running regression testing in the loop script, we come to fail to
start the server. well, the codes may handle the issue when we build without
--enable-debug, but that looks like we have something may break records snap.
open this issue in case someone need it.
{code}
[TrafficServer] using root directory '/opt/ats'
FATAL: RecMessage.cc:426: failed assert `eh-magic == REC_MESSAGE_ELE_MAGIC`
/opt/ats/bin/traffic_server - STACK TRACE:
/opt/ats/lib/libtsutil.so.3(ink_fatal_die+0x0)[0x77baeca1]
/opt/ats/lib/libtsutil.so.3(_Z12ink_get_randv+0x0)[0x77badbb8]
/opt/ats/bin/traffic_server(_Z23RecMessageUnmarshalNextP13RecMessageHdrP13RecMessageItrPP9RecRecord+0xbf)[0x6ed860]
/opt/ats/bin/traffic_server(_Z16RecReadStatsFilev+0xc1)[0x6e5e36]
/opt/ats/bin/traffic_server(_Z11RecCoreInit8RecModeTP5Diags+0xec)[0x6e254b]
/opt/ats/bin/traffic_server(_Z14RecProcessInit8RecModeTP5Diags+0x3b)[0x6e7769]
/opt/ats/bin/traffic_server[0x51d4a5]
/opt/ats/bin/traffic_server(main+0x1df)[0x51ee39]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7515b60d]
/opt/ats/bin/traffic_server[0x4d8f99]
Program received signal SIGABRT, Aborted.
0x7516ec15 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x7516ec15 in raise () from /lib64/libc.so.6
#1 0x7517008b in abort () from /lib64/libc.so.6
#2 0x77baeb2c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77baebfe in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`,
ap=0x7fffc8b8) at ink_error.cc:65
#4 0x77baeca1 in ink_fatal (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x77badbb8 in _ink_assert (expression=0x76ffa0 eh-magic ==
REC_MESSAGE_ELE_MAGIC, file=0x76fe40 RecMessage.cc, line=426)
at ink_assert.cc:38
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
#8 0x006e254b in RecCoreInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecCore.cc:209
#9 0x006e7769 in RecProcessInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecProcess.cc:313
#10 0x0051d4a5 in initialize_process_manager () at Main.cc:413
#11 0x0051ee39 in main (argc=1, argv=0x7fffdd08) at Main.cc:1409
(gdb) f 6
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
(gdb) l
421 itr-ele_hdr = (RecMessageEleHdr *) ((char *) (msg) +
itr-ele_hdr-o_next);
422 itr-next += 1;
423 eh = itr-ele_hdr;
424 }
425
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
427
428 // If the file is corrupt, ignore the the rest of the file.
429 if (eh-magic != REC_MESSAGE_ELE_MAGIC) {
430 Warning(Persistent statistics file records.stat is corrupted.
Ignoring the rest of the file\n);
(gdb) p eh-magic
$1 = 0
(gdb) p REC_MESSAGE_ELE_MAGIC
$2 = 4027445261
(gdb) p eh
$3 = (RecMessageEleHdr *) 0xff4138
(gdb) p *eh
$4 = {magic = 0, o_next = 0}
(gdb) f 7
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
(gdb) l
564 if (RecMessageUnmarshalFirst(m, itr, r) != REC_ERR_FAIL) {
565 do {
566 if ((r-name == NULL) || (!strlen(r-name)))
567 continue;
568 RecSetRecord(r-rec_type, r-name, r-data_type, (r-data),
(r-stat_meta.data_raw), false);
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
570 }
571 }
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874908#comment-13874908
]
Leif Hedstrom commented on TS-1547:
---
Heh, ok, sorry about the confusion. bettydramit, can you try it as per those
instructions ?
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 5.0.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2505) Add command line to disable cache storage device
[
https://issues.apache.org/jira/browse/TS-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874926#comment-13874926
]
James Peach commented on TS-2505:
-
Is {{traffic_line --offline}} a permanent change, or would a {{traffic_server}}
restart bring it back?
Add command line to disable cache storage device
Key: TS-2505
URL: https://issues.apache.org/jira/browse/TS-2505
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 4.1.3
For larger installations it can be very useful to be able to mark a disk
drive as failed before ATS detects that on its own.
At some point in the future a matching ability to bring a drive back online
should be added.
Usage:
{{traffic_line --offline}} _path_
where _path_ is a path used in {{storage.config}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-2137) Use eventfd instead of pthread signal/wait in ATS
[
https://issues.apache.org/jira/browse/TS-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2137.
-
Resolution: Fixed
The reported assertion is no longer in the code. Let's mark this as resolved
and open a new bug if we find any other problems.
Use eventfd instead of pthread signal/wait in ATS
-
Key: TS-2137
URL: https://issues.apache.org/jira/browse/TS-2137
Project: Traffic Server
Issue Type: Improvement
Components: Core, Logging, Stats
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 4.2.0
Attachments:
0001-TS-2137-Forgot-to-add-header-guide-in-EventNotify.h.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V2.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V3.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.V4.patch,
0001-TS-2137-Use-eventfd-instread-of-pthread-signal-wait-.patch,
eventfd_vs_pthread_cond_benchmark.tar.gz
pthread_cond_signal/wait is used in several places in ATS, including but not
limited:
1) Logging system.
2) ProtectedQueue in event system.
3) RecProcess in stats system.
As we known, pthread_cond_signal() needs to take a lock. As such it'll cause
more context switches than eventfd.
I wrote a simple benchmark program to compare the speed of eventfd and
pthread_cond notify mechanism.
You can get the benchmark program from the attachment:
https://issues.apache.org/jira/secure/attachment/12598570/eventfd_vs_pthread_cond_benchmark.tar.gz,
and test it by yourself if interested.
What the program does is:
1) Create 10 producer threads and 1 consumer thread.
2) Producer threads will notify consumer concurrently in a loop.
3) The consumer thread will receive notification up to a given loop time.
Here is my testing result, the command line argument is loop time(100) of
consumer:
{code}
[eventfd_vs_pthread_cond_benchmark]$ ls
main.cc Makefile
[eventfd_vs_pthread_cond_benchmark]$ make
g++ -g -o eventfd_test main.cc -DHAVE_EVENTFD -lpthread
g++ -g -o pthread_cond_test main.cc -lpthread
[eventfd_vs_pthread_cond_benchmark]$ ls
eventfd_test main.cc Makefile pthread_cond_test
[eventfd_vs_pthread_cond_benchmark]$ time ./eventfd_test 100
real0m11.644s
user0m1.517s
sys 1m31.179s
[eventfd_vs_pthread_cond_benchmark]$ time ./pthread_cond_test 100
real0m57.438s
user0m30.152s
sys 6m7.289s
{code}
We can see that eventfd is about 5 times faster than pthread_cond notify
mechanism.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2506) active request timeout leaves client hanging
James Peach created TS-2506:
---
Summary: active request timeout leaves client hanging
Key: TS-2506
URL: https://issues.apache.org/jira/browse/TS-2506
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: James Peach
If you set {{proxy.config.http.transaction_active_timeout_out}} and the origin
response takes too long, the origin end of the HTTP tunnel will get shut down,
but the user agent will never get notified. The user agent just keeps waiting
for a response that will never come.
The HTTP debug log looks like this:
{code}
+ Proxy's Response 2 +
-- State Machine Id: 1
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Thu, 16 Jan 2014 01:06:06 GMT
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/4.2.0
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:6769
(call_transact_and_set_next_state) (http) [1] State Transition:
ORIGIN_SERVER_OPEN - SERVER_READ
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:7278
(do_redirect) (http_redirect) [HttpSM::do_redirect]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1583
(deallocate_redirect_postdata_buffers) (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:584
(add_producer) (http_tunnel) [1] adding producer 'http server'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:640
(add_consumer) (http_tunnel) [1] adding consumer 'user agent'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpSM.cc:5345
(perform_cache_write_action) (http) [1] perform_cache_write_action
CACHE_DO_NO_ACTION
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:686
(tunnel_run) (http_tunnel) tunnel_run started, p_arg is NULL
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:253
(do_io_write) (http_cs) tcp_init_cwnd_set 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:265
(set_tcp_init_cwnd) (http_cs) desired TCP congestion window is 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:905
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.chunked_reader-read_avail() = 184
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:909
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.skip_bytes = 161
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:142
(read_size) (http_chunk) read chunk size of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:217
(read_chunk) (http_chunk) completed read of chunk of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 100
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_READY]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 106
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:2791
(tunnel_handler_server) (http) [1] [HttpSM::tunnel_handler_server,
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_COMPLETE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:3029
(tunnel_handler_ua) (http) [1] [HttpSM::tunnel_handler_ua,
VC_EVENT_WRITE_COMPLETE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpClientSession.cc:592
(release) (http_cs) [1] session released by sm [1]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpClientSession.cc:618
(release) (http_cs) [1] initiating io for next header
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpServerSession.cc:123
(do_io_close) (http_ss) [1] session closed
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:2505
(main_handler) (http) [1] [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:2736
[jira] [Commented] (TS-2505) Add command line to disable cache storage device
[
https://issues.apache.org/jira/browse/TS-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874978#comment-13874978
]
Alan M. Carroll commented on TS-2505:
-
It would be in effect cleared by a restart, the same way ATS detected disk
failure is cleared.
Add command line to disable cache storage device
Key: TS-2505
URL: https://issues.apache.org/jira/browse/TS-2505
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 4.1.3
For larger installations it can be very useful to be able to mark a disk
drive as failed before ATS detects that on its own.
At some point in the future a matching ability to bring a drive back online
should be added.
Usage:
{{traffic_line --offline}} _path_
where _path_ is a path used in {{storage.config}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2506) active request timeout leaves client hanging
[
https://issues.apache.org/jira/browse/TS-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2506:
Fix Version/s: 4.2.0
Assignee: James Peach
I think I'm on the right track to fix this. In
{{HttpSM::tunnel_handler_server}}, we need to figure out the right error state,
and I think that we ought to shut down the whole tunnel with
{{tunnel.chain_abort_all()}}. Currently, the error path in this code calls
{{tunnel.abort_cache_write_finish_others()}}, but I don't think that the
downstream consumers should be allowed to persist because they need to be
notified of the error, and there's no way for them to handle the partial
response.
active request timeout leaves client hanging
Key: TS-2506
URL: https://issues.apache.org/jira/browse/TS-2506
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: James Peach
Assignee: James Peach
Fix For: 4.2.0
If you set {{proxy.config.http.transaction_active_timeout_out}} and the
origin response takes too long, the origin end of the HTTP tunnel will get
shut down, but the user agent will never get notified. The user agent just
keeps waiting for a response that will never come.
The HTTP debug log looks like this:
{code}
+ Proxy's Response 2 +
-- State Machine Id: 1
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Thu, 16 Jan 2014 01:06:06 GMT
Age: 0
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/4.2.0
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:6769
(call_transact_and_set_next_state) (http) [1] State Transition:
ORIGIN_SERVER_OPEN - SERVER_READ
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpSM.cc:7278
(do_redirect) (http_redirect) [HttpSM::do_redirect]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:1583
(deallocate_redirect_postdata_buffers) (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Jan 15 17:06:06.612] Server {0x109267000} DEBUG: HttpTunnel.cc:584
(add_producer) (http_tunnel) [1] adding producer 'http server'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:640
(add_consumer) (http_tunnel) [1] adding consumer 'user agent'
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpSM.cc:5345
(perform_cache_write_action) (http) [1] perform_cache_write_action
CACHE_DO_NO_ACTION
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:686
(tunnel_run) (http_tunnel) tunnel_run started, p_arg is NULL
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:253
(do_io_write) (http_cs) tcp_init_cwnd_set 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpClientSession.cc:265
(set_tcp_init_cwnd) (http_cs) desired TCP congestion window is 0
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:905
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.chunked_reader-read_avail() = 184
[Jan 15 17:06:06.613] Server {0x109267000} DEBUG: HttpTunnel.cc:909
(producer_run) (http_tunnel) [producer_run] do_dechunking
p-chunked_handler.skip_bytes = 161
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_READ_READY]
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:142
(read_size) (http_chunk) read chunk size of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:217
(read_chunk) (http_chunk) completed read of chunk of 17 bytes
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 100
[Jan 15 17:06:06.614] Server {0x109267000} DEBUG: HttpTunnel.cc:1240
(consumer_handler) (http_tunnel) [1] consumer_handler [user agent
VC_EVENT_WRITE_READY]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1052
(producer_handler) (http_tunnel) [1] producer_handler [http server
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:989
(producer_handler_chunked) (http_tunnel) [1] producer_handler_chunked [http
server VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.610] Server {0x109267000} DEBUG: HttpTunnel.cc:1093
(producer_handler) (http_redirect) [HttpTunnel::producer_handler]
enable_redirection: [1 0 0] event: 106
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG: HttpSM.cc:2791
(tunnel_handler_server) (http) [1] [HttpSM::tunnel_handler_server,
VC_EVENT_ACTIVE_TIMEOUT]
[Jan 15 17:06:08.612] Server {0x109267000} DEBUG:
[jira] [Closed] (TS-2011) Merge channel_stats and stats_over_http plus improvements
[ https://issues.apache.org/jira/browse/TS-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2011. --- Resolution: Unresolved Fix Version/s: (was: 5.0.0) 4.2.0 This was resolved in a different way. Created a new plugin that puts per remap stats into the REC system and stats_over_http can print that out. Merge channel_stats and stats_over_http plus improvements - Key: TS-2011 URL: https://issues.apache.org/jira/browse/TS-2011 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Labels: C Fix For: 4.2.0 Have all applicable stats in stats_over_http by channel (remap). Also add new bandwidth related metrics, make JSON versioned, and make URL configurable (TS-1998). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874998#comment-13874998
]
James Peach commented on TS-1648:
-
[~briang] what is needed to test this fix?
Segmentation fault in dir_clear_range()
---
Key: TS-1648
URL: https://issues.apache.org/jira/browse/TS-1648
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.3.0, 3.2.0
Environment: reverse proxy
Reporter: Tomasz Kuzemko
Assignee: John Plevyak
Labels: A
Fix For: 3.3.4
Attachments:
0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch,
cachedir_int64-jp-1.patch
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
2x 10TB raw disks. I do not use cache compression. After a few days of
running (this is a dev machine - not handling any traffic) ATS begins to
crash with a segfault shortly after start:
{code}
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
snap 1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024,
vol=0x16057d0) at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
{code}
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide
more data. I tried to make a core dump but it took a couple of GB even after
gzip (I can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2054) traffic_server will not bind to a reserved port (=1024)
[ https://issues.apache.org/jira/browse/TS-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2054: --- Assignee: Alan M. Carroll (was: Phil Sorber) Assigning to Alan as he seems to have the ball on this based on the comments. traffic_server will not bind to a reserved port (=1024) Key: TS-2054 URL: https://issues.apache.org/jira/browse/TS-2054 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Assignee: Alan M. Carroll Priority: Minor Fix For: 6.0.0 At some point after ea560ce I stopped being able to bind to port 80. It looks like I can bind above port 1024 though. Perhaps we are dropping privs before binding the port now? I used --enable-debug when configuring. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2504) Fix crypto.m4 when detect openssl library in 64bit OS
[
https://issues.apache.org/jira/browse/TS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2504:
Description:
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
was:
From [~jamespeach]:
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
Fix crypto.m4 when detect openssl library in 64bit OS
-
Key: TS-2504
URL: https://issues.apache.org/jira/browse/TS-2504
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2504) Fix crypto.m4 when detect openssl library in 64bit OS
[
https://issues.apache.org/jira/browse/TS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875004#comment-13875004
]
James Peach commented on TS-2504:
-
I can take care of this if you like.
Fix crypto.m4 when detect openssl library in 64bit OS
-
Key: TS-2504
URL: https://issues.apache.org/jira/browse/TS-2504
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2088: Fix Version/s: (was: 6.0.0) sometime Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: sometime This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2504) Fix crypto.m4 when detect openssl library in 64bit OS
[
https://issues.apache.org/jira/browse/TS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2504:
-
Assignee: James Peach (was: Yunkai Zhang)
Fix crypto.m4 when detect openssl library in 64bit OS
-
Key: TS-2504
URL: https://issues.apache.org/jira/browse/TS-2504
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Yunkai Zhang
Assignee: James Peach
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2504) Fix crypto.m4 when detect openssl library in 64bit OS
[
https://issues.apache.org/jira/browse/TS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875014#comment-13875014
]
Yunkai Zhang commented on TS-2504:
--
assigned to you:), thank you!
Fix crypto.m4 when detect openssl library in 64bit OS
-
Key: TS-2504
URL: https://issues.apache.org/jira/browse/TS-2504
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Yunkai Zhang
Assignee: James Peach
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2282) Allow ATS to run with empty config
[ https://issues.apache.org/jira/browse/TS-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2282: --- Assignee: Phil Sorber Allow ATS to run with empty config -- Key: TS-2282 URL: https://issues.apache.org/jira/browse/TS-2282 Project: Traffic Server Issue Type: Sub-task Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.0.0 Traffic server should start and run with empty config files using the defaults. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2504) Fix crypto.m4 when detect openssl library in 64bit OS
[
https://issues.apache.org/jira/browse/TS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875018#comment-13875018
]
James Peach commented on TS-2504:
-
Woohoo!
BTW, how do you get OpenSSL to install to {{$PREFIX/lib64}}? On the platforms I
use, it always installs to {{$PREFIX/lib}} ...
Fix crypto.m4 when detect openssl library in 64bit OS
-
Key: TS-2504
URL: https://issues.apache.org/jira/browse/TS-2504
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Yunkai Zhang
Assignee: James Peach
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2284) Run with no configs
[ https://issues.apache.org/jira/browse/TS-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2284: --- Assignee: Leif Hedstrom Run with no configs --- Key: TS-2284 URL: https://issues.apache.org/jira/browse/TS-2284 Project: Traffic Server Issue Type: Sub-task Reporter: Phil Sorber Assignee: Leif Hedstrom Fix For: 5.0.0 In addition to running with empty configs (TS-2282), we should be able to run with no configs and not write them out (TS-2283). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-315: --- Issue Type: Sub-task (was: Improvement) Parent: TS-2281 Add switch to disable config file generation/runtime behavior changing -- Key: TS-315 URL: https://issues.apache.org/jira/browse/TS-315 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Miles Libbey Priority: Minor Fix For: 5.0.0 (was yahoo bug 1863676) Original description by Michael S. Fischer 2 years ago at 2008-04-09 09:52 In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own configuration files. For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than 'traffic_line -x' (including the web interface, etc.) Comment 1 by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages we'd like to think that the content of these files can't change outside our control. Comment 2 by Bryan Call 2 years ago at 2008-04-09 11:02:46 traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1). It would be an equivalent of write protecting floppies (ahh the memories)... Comment 3 by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg problem. Comment 4 by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 So I'm not 100% positive that this isn't just a bad interaction. Now, it's only triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which looks like it's the default config that comes with the trafficserver package. It's possible it's all one and the same issue, or we might have two issues. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2504) Fix crypto.m4 when detect openssl library in 64bit OS
[
https://issues.apache.org/jira/browse/TS-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875037#comment-13875037
]
Yunkai Zhang commented on TS-2504:
--
Actually I don't know:)
The OpenSSL's RPM was created by another team at Taobao.
Whant I think is that, in 64bit OS, some 64bit library may installed in
xxx/lib64, it looks reasonable.
Fix crypto.m4 when detect openssl library in 64bit OS
-
Key: TS-2504
URL: https://issues.apache.org/jira/browse/TS-2504
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Yunkai Zhang
Assignee: James Peach
From [~jamespeach]:
{quote}
Yunkai Zhang can you split
0007-Fix-crypto.m4-when-detect-openssl-library-in-64bit-O.V2.patch into a
separate Jira ticket?
Shall we use
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_openssl.m4
to improve OpenSSL detection?
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2507) HttpSM::handle_server_setup_error logs the wrong state transition
James Peach created TS-2507:
---
Summary: HttpSM::handle_server_setup_error logs the wrong state
transition
Key: TS-2507
URL: https://issues.apache.org/jira/browse/TS-2507
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: James Peach
{{HttpSM::handle_server_setup_error}} passes the wrong fields to
{{STATE_ENTER}}, so it logs the state transition incorrectly.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-2507) HttpSM::handle_server_setup_error logs the wrong state transition
[
https://issues.apache.org/jira/browse/TS-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2507.
-
Resolution: Fixed
HttpSM::handle_server_setup_error logs the wrong state transition
-
Key: TS-2507
URL: https://issues.apache.org/jira/browse/TS-2507
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 4.2.0
{{HttpSM::handle_server_setup_error}} passes the wrong fields to
{{STATE_ENTER}}, so it logs the state transition incorrectly.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2508) add experimental escalation plugin
[ https://issues.apache.org/jira/browse/TS-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2508: Priority: Minor (was: Major) Fix Version/s: 4.2.0 Assignee: James Peach add experimental escalation plugin -- Key: TS-2508 URL: https://issues.apache.org/jira/browse/TS-2508 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 4.2.0 Add an experimental escalation plugin. This plugin is *really* experimental, since it calls APIs that crash 100% of the time. However it is a good test case to fix those APIs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2509) make HttpTunnel methods const
[ https://issues.apache.org/jira/browse/TS-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2509: Priority: Trivial (was: Major) Fix Version/s: 4.2.0 Assignee: James Peach make HttpTunnel methods const - Key: TS-2509 URL: https://issues.apache.org/jira/browse/TS-2509 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: James Peach Assignee: James Peach Priority: Trivial Fix For: 4.2.0 A number of HttpTunnel methods could be make const; let's do that then. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2509) make HttpTunnel methods const
James Peach created TS-2509: --- Summary: make HttpTunnel methods const Key: TS-2509 URL: https://issues.apache.org/jira/browse/TS-2509 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: James Peach A number of HttpTunnel methods could be make const; let's do that then. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2509) make HttpTunnel methods const
[ https://issues.apache.org/jira/browse/TS-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875256#comment-13875256 ] ASF subversion and git services commented on TS-2509: - Commit 0fc0820b5dfdd322aea465853ff9f446a475ba50 in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0fc0820 ] TS-2509: add const qualifier to pure HttpTunnel member functions make HttpTunnel methods const - Key: TS-2509 URL: https://issues.apache.org/jira/browse/TS-2509 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: James Peach Assignee: James Peach Priority: Trivial Fix For: 4.2.0 A number of HttpTunnel methods could be make const; let's do that then. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2509) make HttpTunnel methods const
[ https://issues.apache.org/jira/browse/TS-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2509. - Resolution: Fixed make HttpTunnel methods const - Key: TS-2509 URL: https://issues.apache.org/jira/browse/TS-2509 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: James Peach Assignee: James Peach Priority: Trivial Fix For: 4.2.0 A number of HttpTunnel methods could be make const; let's do that then. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
