[jira] [Resolved] (TS-1121) --disable-diags configuration option does not do anything
[ https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1121. --- Resolution: Fixed Fixed in 0db892e25817c67c5994c527862e1eaa341be307 --disable-diags configuration option does not do anything - Key: TS-1121 URL: https://issues.apache.org/jira/browse/TS-1121 Project: Traffic Server Issue Type: Bug Components: Build, Core Affects Versions: 3.0.3 Environment: any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Original Estimate: 2h Remaining Estimate: 2h The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is defined or not -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248161#comment-13248161 ] Leif Hedstrom commented on TS-1079: --- If I understand the original design correctly, the idea was that DebugSpecific() would work just like the old Debug() when not being specific. But when enabled e.g. in a transaction or session, it would override the global defaults. So when the flag is true, it will always print the debug info, but when false it depends on whatever the global diags flag is. The public TSDebugSpecific() API follows the same pattern as the core version I assume. Meaning, a plugin can now call TSDebugSpecific() in a way that it uses the global diagnostics settings when false, but forcing the Debug() when true. This seems generally useful to me. Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248161#comment-13248161 ] Leif Hedstrom edited comment on TS-1079 at 4/6/12 7:47 AM: --- If I understand the original design correctly, the idea was that DebugSpecific() would work just like the old Debug() when not being specific. But when enabled e.g. in a transaction or session, it would override the global defaults. So when the flag is true, it will always print the debug info, but when false it depends on whatever the global diags settings are. The public TSDebugSpecific() API follows the same pattern as the core version I assume. Meaning, a plugin can now call TSDebugSpecific() in a way that it uses the global diagnostics settings when false, but forcing the Debug() when true. This seems generally useful to me. was (Author: zwoop): If I understand the original design correctly, the idea was that DebugSpecific() would work just like the old Debug() when not being specific. But when enabled e.g. in a transaction or session, it would override the global defaults. So when the flag is true, it will always print the debug info, but when false it depends on whatever the global diags flag is. The public TSDebugSpecific() API follows the same pattern as the core version I assume. Meaning, a plugin can now call TSDebugSpecific() in a way that it uses the global diagnostics settings when false, but forcing the Debug() when true. This seems generally useful to me. Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1103) Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248517#comment-13248517 ] Zhao Yongming commented on TS-1103: --- hmm, I think the codes may need more cleanup, so far we have now a working base. Traffic Server ESI plugin issues Key: TS-1103 URL: https://issues.apache.org/jira/browse/TS-1103 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: sometime Environment: Newest trunk. Reporter: Kevin Fox Assignee: Zhao Yongming Fix For: 3.1.4 Attachments: esi.patch, gzip.patch Patch to fix: * Makefile fix to add missing files. * Change return code checking to match whats trunk trafficserver. * Include missing header files. * Fix c++ namespace issues. * Work around strange name mangling/linking issue. * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI. Things wouldn't work without it. * Comment out a block of code that looked to be incorrectly handling EOF. After this, simply loading the plugin and setting response header X-ESI in apache httpd seems to work. A few further bugs I have bumped into that aren't addressed in this patch: * It doesn't seem to parse gzip like it looks like it should. To work around, I had to disable it in apache httpd with RewriteRule . - [E=no-gzip:1] * If the client requests gzip, the ESI processor will gzip the result. It works in firefox but is invalid in chrome. Pulling a dump with curl and running it through gzip --list shows it has the correct uncompressed size and compressed size. using zcat shows the correct data but has the warning: invalid compressed data--length error. As far as I read the gzip spec though, the raw binary file looks valid to me. Not sure what this is. This can probably be simply disabled for now though. * esi:include is slightly broken. You get all the data back properly but sometimes the headers are sent prematurely with a Content-Length of 2**31-1. This causes clients to timeout and fail. I'm currently unsure how to fix this. I've tried a few of the more advanced esi features, including ensuring cookies make it back to the origin server and things seem to work good. So, once the above bugs are figured out (particularly the include one), I think it will be in pretty good shape. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)
[
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming closed TS-968.
Resolution: Cannot Reproduce
close for now, reopen if it is still valid.
During/after daily logfile roll, trafficserver seg faults (Sig 11)
--
Key: TS-968
URL: https://issues.apache.org/jira/browse/TS-968
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.0.1
Environment: Ubuntu 10.10, 2.6.35-24-virtual
Reporter: Drew Rothstein
Assignee: Zhao Yongming
Fix For: 3.1.4
Every day at 00:00:00 after/during the log file roll, I see a segfault. Here
are the past couple days:
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/error.log was rolled to
/usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/squid.log was rolled to
/usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/extended2.log was rolled to
/usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
[Sep 22 00:00:17.729] Manager {140722071643936} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Sep 22 00:00:17.729] Manager {140722071643936} FATAL: (last system error
104: Connection reset by peer)
[Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Sep 22 00:00:17.730] Manager {140722071643936} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Sep 22 00:00:17.730] Manager {140722071643936} ERROR: (last system error
32: Broken pipe)
[E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
[Sep 22 00:00:17.786] {140131209512736} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.35-24-virtual'
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup
complete
[Sep 22 00:00:18.827] Manager {140131209512736} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr/local'
[Sep 22 00:00:18.849] Manager {140131209512736} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm]
Server Process born
[Sep 22 00:00:19.874] {47510015031936} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
[Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
[Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
[Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7],
logging_mode = 3
[Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
[Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/error.log was rolled to
/usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/squid.log was rolled to
/usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/extended2.log was rolled to
/usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
[Sep 23 00:00:14.668] Manager {140131209512736} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Sep 23 00:00:14.668] Manager {140131209512736} FATAL: (last system error
104: Connection reset by peer)
[Sep 23 00:00:14.668] Manager {140131209512736} NOTE:
[jira] [Resolved] (TS-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1147. - Resolution: Fixed 5fe79e6 TS-1147: Remove last cert.filename and private_key.filename references cadc9b6 TS-1147: Implement default certificate fallback. e2827c0 TS-1147: Remove default server SSL_CTX from SSLNetProcessor a238d13 TS-1147: Remove proxy.config.ssl.server.private_key.filename c426f4a TS-1147: Remove proxy.config.ssl.server.cert.filename 47255d3 TS-1147: Remove defaultEnabled flag from SSLNetProcessor::initSSLServerCTX() e7d5784 TS-1147: Remove SSLNetProcessor::initSSL() Someone please review! deprecate records.config SSL configuration -- Key: TS-1147 URL: https://issues.apache.org/jira/browse/TS-1147 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.5 Since ssl_multicert.config is a strict superset of the SSL certificate configuration in records.config, we should deprecate configuring SSL certificates in records.config and make ssl_multicert.config the One True Way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
