[jira] [Created] (TS-1099) review of squid replacement algorithm
review of squid replacement algorithm - Key: TS-1099 URL: https://issues.apache.org/jira/browse/TS-1099 Project: Traffic Server Issue Type: Sub-task Reporter: Eric Ahn Priority: Minor -- 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-1099) review of squid replacement algorithm
[ https://issues.apache.org/jira/browse/TS-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197158#comment-13197158 ] Eric Ahn commented on TS-1099: -- It should review for replacement algorithm to supply a various replacement method on ATS. review of squid replacement algorithm - Key: TS-1099 URL: https://issues.apache.org/jira/browse/TS-1099 Project: Traffic Server Issue Type: Sub-task Components: Plugins Reporter: Eric Ahn Priority: Minor Fix For: Doc 3.0 -- 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] [Updated] (TS-1099) review of squid replacement algorithm
[ https://issues.apache.org/jira/browse/TS-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Ahn updated TS-1099: - Component/s: (was: Documentation) Plugins review of squid replacement algorithm - Key: TS-1099 URL: https://issues.apache.org/jira/browse/TS-1099 Project: Traffic Server Issue Type: Sub-task Components: Plugins Reporter: Eric Ahn Priority: Minor Fix For: Doc 3.0 -- 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-337) Cache Replacement Algorithm plug-in API
[ https://issues.apache.org/jira/browse/TS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197156#comment-13197156 ] Eric Ahn commented on TS-337: - Leif, Is this issue plugin component? Cache Replacement Algorithm plug-in API --- Key: TS-337 URL: https://issues.apache.org/jira/browse/TS-337 Project: Traffic Server Issue Type: New Feature Components: Documentation Affects Versions: 2.0.0 Reporter: Mark Nottingham Fix For: Doc 3.0 New cache replacement algorithms are often proposed, and often it's not a one size fits all problem; different workloads require different approaches. To facilitate this, TS should have a pluggable cache replacement policy API, both for the memory and disk cache. Squid has done this to good effect; see http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/repl/ -- 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-1094) TS hangs after repeated requests from the same kept-alive connection
[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197348#comment-13197348 ] Wilson Ho commented on TS-1094: --- I can no longer reproduce the problem with this fix. Thank you very much! You seem to have reservations on the fix itself. Do you plan to fix it in a different way, or is this good enough? Thanks! Wilson TS hangs after repeated requests from the same kept-alive connection Key: TS-1094 URL: https://issues.apache.org/jira/browse/TS-1094 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Oracle Enterprise Linux 5.5 64-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 When a client submits multiple requests while re-using the same keep-alived connection, TS hangs. Usually, the client eventually times out, and at that point TS will be waken up and forwards the request to the original server. But by then it's too late and the client already closed connection. In real life traffic, this bug is very hard to reproduce. But here is an artificial test case. First, make sure client-side keep alive is on. My test case uses HTTP (port 80) GET. Second, make sure the total header size of the requests is exactly 275 bytes, including the carriage returns and line feeds. One byte more or less would fail to reproduce the bug. Third, repeatedly submit the same request through this keep-alived connection. At exactly the 283rd iteration, TS hangs. Note that if the client opens a new connection every time, TS works fine. There is a second test case, where the header size is exactly 283 bytes, and TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) These magic numbers seem to suggest a memory buffer size (or allocation) problem. I speculate that headers from repeated requests are placed in a buffer (or a circular buffer?), and when the total hits a particular size, some boundary conditions must have be violated and resulted in memory corruption. In real life traffic, each request typically has slightly different header size, so it is really hard to hit this bug. I suspect there is a +/- 1 calculation error in some buffer. BTW, turning on/off caching does not make any difference. -- 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-1094) TS hangs after repeated requests from the same kept-alive connection
[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197364#comment-13197364 ] Leif Hedstrom commented on TS-1094: --- Yeah, it needs a different fix. But, glad to hear it works for you, means at least I'm on the right track. Unfortunately $work is getting in the way right now, but I'll work more on this soon (and Alan promised to help too, since it's his fault ;). TS hangs after repeated requests from the same kept-alive connection Key: TS-1094 URL: https://issues.apache.org/jira/browse/TS-1094 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Oracle Enterprise Linux 5.5 64-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 When a client submits multiple requests while re-using the same keep-alived connection, TS hangs. Usually, the client eventually times out, and at that point TS will be waken up and forwards the request to the original server. But by then it's too late and the client already closed connection. In real life traffic, this bug is very hard to reproduce. But here is an artificial test case. First, make sure client-side keep alive is on. My test case uses HTTP (port 80) GET. Second, make sure the total header size of the requests is exactly 275 bytes, including the carriage returns and line feeds. One byte more or less would fail to reproduce the bug. Third, repeatedly submit the same request through this keep-alived connection. At exactly the 283rd iteration, TS hangs. Note that if the client opens a new connection every time, TS works fine. There is a second test case, where the header size is exactly 283 bytes, and TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) These magic numbers seem to suggest a memory buffer size (or allocation) problem. I speculate that headers from repeated requests are placed in a buffer (or a circular buffer?), and when the total hits a particular size, some boundary conditions must have be violated and resulted in memory corruption. In real life traffic, each request typically has slightly different header size, so it is really hard to hit this bug. I suspect there is a +/- 1 calculation error in some buffer. BTW, turning on/off caching does not make any difference. -- 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-1094) TS hangs after repeated requests from the same kept-alive connection
[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197371#comment-13197371 ] Alan M. Carroll commented on TS-1094: - In theory that fix should potentially cause duplicated header data internally. The assignment is used to prevent data already copied to the output data structures from being copied again. Very odd that it fixes this problem. TS hangs after repeated requests from the same kept-alive connection Key: TS-1094 URL: https://issues.apache.org/jira/browse/TS-1094 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Oracle Enterprise Linux 5.5 64-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 When a client submits multiple requests while re-using the same keep-alived connection, TS hangs. Usually, the client eventually times out, and at that point TS will be waken up and forwards the request to the original server. But by then it's too late and the client already closed connection. In real life traffic, this bug is very hard to reproduce. But here is an artificial test case. First, make sure client-side keep alive is on. My test case uses HTTP (port 80) GET. Second, make sure the total header size of the requests is exactly 275 bytes, including the carriage returns and line feeds. One byte more or less would fail to reproduce the bug. Third, repeatedly submit the same request through this keep-alived connection. At exactly the 283rd iteration, TS hangs. Note that if the client opens a new connection every time, TS works fine. There is a second test case, where the header size is exactly 283 bytes, and TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) These magic numbers seem to suggest a memory buffer size (or allocation) problem. I speculate that headers from repeated requests are placed in a buffer (or a circular buffer?), and when the total hits a particular size, some boundary conditions must have be violated and resulted in memory corruption. In real life traffic, each request typically has slightly different header size, so it is really hard to hit this bug. I suspect there is a +/- 1 calculation error in some buffer. BTW, turning on/off caching does not make any difference. -- 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] [Created] (TS-1100) Coredump at startup when there's a duplicate remap rule
Coredump at startup when there's a duplicate remap rule --- Key: TS-1100 URL: https://issues.apache.org/jira/browse/TS-1100 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.1 Environment: Bog standard linux/x86; own build. Reporter: Nick Kew Priority: Minor A minor accident with cutpaste in vi leads to TS coredumping at startup. I had duplicated a line in remap.config: map http://myhost:8080/ http://target/ () map http://myhost:8080/ http://target/ The second instance is line 125 in remap.config, and the dump shows: FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 125 bin/traffic_server - STACK TRACE: /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0xe21873] /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal+0x2b)[0xe218c5] bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x1e48)[0x81e1120] bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x562)[0x810] bin/traffic_server(_Z18init_reverse_proxyv+0x41)[0x815500b] bin/traffic_server(_Z20init_HttpProxyServerv+0xe)[0x818fccc] bin/traffic_server(main+0xf7f)[0x813b65d] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x692bd6] bin/traffic_server[0x80f6001] Aborted -- 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-1100) Coredump at startup when there's a duplicate remap rule
[ https://issues.apache.org/jira/browse/TS-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197416#comment-13197416 ] Leif Hedstrom commented on TS-1100: --- This is sort of by design, it refuses to start up with a bad remap.config. The reason you get a segfault is because our destructors are running on uninitialized objects :-/. Coredump at startup when there's a duplicate remap rule --- Key: TS-1100 URL: https://issues.apache.org/jira/browse/TS-1100 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.1 Environment: Bog standard linux/x86; own build. Reporter: Nick Kew Priority: Minor A minor accident with cutpaste in vi leads to TS coredumping at startup. I had duplicated a line in remap.config: map http://myhost:8080/ http://target/ () map http://myhost:8080/ http://target/ The second instance is line 125 in remap.config, and the dump shows: FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 125 bin/traffic_server - STACK TRACE: /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0xe21873] /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal+0x2b)[0xe218c5] bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x1e48)[0x81e1120] bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x562)[0x810] bin/traffic_server(_Z18init_reverse_proxyv+0x41)[0x815500b] bin/traffic_server(_Z20init_HttpProxyServerv+0xe)[0x818fccc] bin/traffic_server(main+0xf7f)[0x813b65d] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x692bd6] bin/traffic_server[0x80f6001] Aborted -- 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] [Assigned] (TS-1014) slow log can not print logs well on 32-bit system, I changed the %d to RPI64
[ https://issues.apache.org/jira/browse/TS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1014: -- Assignee: Igor Galić (was: Leif Hedstrom) slow log can not print logs well on 32-bit system, I changed the %d to RPI64 Key: TS-1014 URL: https://issues.apache.org/jira/browse/TS-1014 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.0 Environment: 32-bit system Reporter: weijin Assignee: Igor Galić Priority: Minor Fix For: 3.1.2, 3.0.3 Attachments: slow_log.diff -- 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] [Updated] (TS-830) traffic_line -r returns Variable Not Found, even if it's a permission issue
[
https://issues.apache.org/jira/browse/TS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-830:
--
Fix Version/s: 3.0.3
traffic_line -r returns Variable Not Found, even if it's a permission issue
-
Key: TS-830
URL: https://issues.apache.org/jira/browse/TS-830
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.0, 2.1.9
Reporter: Igor Galić
Assignee: Igor Galić
Priority: Minor
Fix For: 3.1.1, 3.0.3
Attachments: ts830.patch
Example:
{noformat}
i.galic@pheme ~ % /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
1 i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
NULL
i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
{noformat}
I propose we tell the user, when it's actually a permission problem.
--
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] [Updated] (TS-1046) Add possibility to extend tsxs command line for -Iincludes
[ https://issues.apache.org/jira/browse/TS-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1046: --- Backport to Version: (was: 3.0.3) Fix Version/s: 3.0.3 Add possibility to extend tsxs command line for -Iincludes -- Key: TS-1046 URL: https://issues.apache.org/jira/browse/TS-1046 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 3.1.1, 3.0.2 Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.1.2, 3.0.3 Already commited in r1212075 -- 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] [Resolved] (TS-1046) Add possibility to extend tsxs command line for -Iincludes
[ https://issues.apache.org/jira/browse/TS-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-1046. Resolution: Fixed Add possibility to extend tsxs command line for -Iincludes -- Key: TS-1046 URL: https://issues.apache.org/jira/browse/TS-1046 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 3.1.1, 3.0.2 Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.1.2, 3.0.3 Already commited in r1212075 -- 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] [Assigned] (TS-830) traffic_line -r returns Variable Not Found, even if it's a permission issue
[
https://issues.apache.org/jira/browse/TS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-830:
-
Assignee: Igor Galić (was: Leif Hedstrom)
traffic_line -r returns Variable Not Found, even if it's a permission issue
-
Key: TS-830
URL: https://issues.apache.org/jira/browse/TS-830
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.0, 2.1.9
Reporter: Igor Galić
Assignee: Igor Galić
Priority: Minor
Fix For: 3.1.1, 3.0.3
Attachments: ts830.patch
Example:
{noformat}
i.galic@pheme ~ % /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
1 i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
NULL
i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
{noformat}
I propose we tell the user, when it's actually a permission problem.
--
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] [Created] (TS-1101) traffic_line -x doesn't seem to work
traffic_line -x doesn't seem to work Key: TS-1101 URL: https://issues.apache.org/jira/browse/TS-1101 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 traffic_line -x doesn't seem to work any more. -- 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] [Resolved] (TS-1101) traffic_line -x doesn't seem to work
[ https://issues.apache.org/jira/browse/TS-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1101. --- Resolution: Fixed traffic_line -x doesn't seem to work Key: TS-1101 URL: https://issues.apache.org/jira/browse/TS-1101 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 traffic_line -x doesn't seem to work any more. -- 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-1084) enable compile-time format string checking
[ https://issues.apache.org/jira/browse/TS-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197579#comment-13197579 ] James Peach commented on TS-1084: - Commit 9b3bae3644bc302aa7587b225bb4340b52219436 and following. enable compile-time format string checking -- Key: TS-1084 URL: https://issues.apache.org/jira/browse/TS-1084 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: James Peach Priority: Minor Attachments: 0001-TS-1084-Add-format-string-checking.patch Add format string checking. Add format string checking to internal and external APIs that take a printf(3) format string. No functional changes. Fix all the resulting warnings - time_t is formatted as long long for portability - size_t became %zu - pointers all became %p -- 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-1101) traffic_line -x doesn't seem to work
[ https://issues.apache.org/jira/browse/TS-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197602#comment-13197602 ] bettydramit commented on TS-1101: - any one Resolved this issue? traffic_line -x doesn't seem to work Key: TS-1101 URL: https://issues.apache.org/jira/browse/TS-1101 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 traffic_line -x doesn't seem to work any more. -- 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
