[jira] [Resolved] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1077. - Resolution: Fixed Committed patch. See the attached ts-1077.txt for more detail on the changes. HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.2 Attachments: ts-1077.diff, ts-1077.txt The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- 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-1088) Allow Per-transaction Transparency (TProxy) Override
[ https://issues.apache.org/jira/browse/TS-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1088. - Resolution: Fixed Commit 1236723. Changed function to TSHttpTxnOutgoingTransparencySet to be more consistent. Allow Per-transaction Transparency (TProxy) Override Key: TS-1088 URL: https://issues.apache.org/jira/browse/TS-1088 Project: Traffic Server Issue Type: New Feature Components: HTTP, TS API Affects Versions: 3.1.0 Environment: The feature was built on top of a 3.1.0 release candidate, however only minor adjustments are needed for HEAD Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: tsapi-allow-transparency.patch Address level transparency (using TProxy) is propagated forward from the incoming connection based on global configuration. This feature allows internal and external systems that use the TS api to disable propagation on a per transaction basis. The result is that the client=proxy connection transparently appears as a client=origin server connection and the proxy=origin server connection is opaque. -- 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-17) Expose atomic abstractions via InkAPI
[ https://issues.apache.org/jira/browse/TS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-17. - Resolution: Won't Fix Fix Version/s: (was: 3.3.0) I think this is a moot point now, people should just use the standard gcc atomics. Expose atomic abstractions via InkAPI - Key: TS-17 URL: https://issues.apache.org/jira/browse/TS-17 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor With the changes being made to the atomic abstractions, we should take this opportunity to expose atomic APIs via InkAPI (InkAPI.h). Breaking API or binarby ABIs is not a problem. Doing this, will make it easier to use atomic instructions in plugins, and keep the plugins cross platform. -- 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-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as
[ https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1061: -- Fix Version/s: (was: 3.1.1) 3.1.2 Assignee: Leif Hedstrom I think this slipped under the radar, due to the old fix version (3.1.1 was released a while ago). TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as it is not used. - Key: TS-1061 URL: https://issues.apache.org/jira/browse/TS-1061 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.1.1, 3.0.1 Environment: Redhat Linux but it is not environment specific Reporter: Alistair Stevenson Assignee: Leif Hedstrom Priority: Minor Labels: api-change Fix For: 3.1.2 Original Estimate: 1h Remaining Estimate: 1h The definitions are: ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes) ./proxy/api/ts/ts.h.in: tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp); The int * bytes parameter is not used and means that the function does not resolve and so cannot be used. -- 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-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a
[ https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1061. --- Resolution: Fixed Committed on trunk, sorry for tardiness, please keep 'em bug reports coming! TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as it is not used. - Key: TS-1061 URL: https://issues.apache.org/jira/browse/TS-1061 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.1.1, 3.0.1 Environment: Redhat Linux but it is not environment specific Reporter: Alistair Stevenson Assignee: Leif Hedstrom Priority: Minor Labels: api-change Fix For: 3.1.2 Original Estimate: 1h Remaining Estimate: 1h The definitions are: ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes) ./proxy/api/ts/ts.h.in: tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp); The int * bytes parameter is not used and means that the function does not resolve and so cannot be used. -- 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-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1089: Attachment: ts-1089.diff Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: trans-pluginvc.patch, ts-1089.diff Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- 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-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1089: Attachment: ts-1089.diff Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: trans-pluginvc.patch, ts-1089.diff Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- 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-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1089: Attachment: (was: ts-1089.diff) Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: trans-pluginvc.patch, ts-1089.diff Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- 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-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1089. - Resolution: Fixed Commit 1236915. Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Assignee: Alan M. Carroll Fix For: 3.1.2 Attachments: trans-pluginvc.patch, ts-1089.diff Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- 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-961) Extend TS API to support TSNetAccept with inbound transparency
[ https://issues.apache.org/jira/browse/TS-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195201#comment-13195201 ] Alan M. Carroll commented on TS-961: I need to look at this again for 3.1.3. The TS-1077 changes should make this much easier. I think I will just go with TSNetTransparentAccept(). Extend TS API to support TSNetAccept with inbound transparency -- Key: TS-961 URL: https://issues.apache.org/jira/browse/TS-961 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Yossi Gottlieb Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.3 Attachments: api_transparency.diff This is required for protocol plugins to use this capability. -- 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-1094) TS hangs after repeated requests from the same kept-alive connection
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 Priority: Blocker 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=13195230#comment-13195230 ] Wilson Ho commented on TS-1094: --- 275 x 283 = (19 x 4096) + 1. I think the buffer size is a multiple of 4KB and this case hits a 1+ error. 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 Priority: Blocker 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] [Updated] (TS-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-876: Backport to Version: (was: 3.0.3) forward map based on request receive port - Key: TS-876 URL: https://issues.apache.org/jira/browse/TS-876 Project: Traffic Server Issue Type: New Feature Components: Remap API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 3.1.0 Attachments: map_with_recv_port.patch Currently the port in the from fields of all remap rules are compared against the port in the request (explicitly in the request or implicitly deduced from the protocol). TS supports listening on multiple ports, so there is a use case for a remap rule that uses the TS port at which the request is received instead of the request port. -- 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-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-876: Attachment: TS876.fixed.patch forward map based on request receive port - Key: TS-876 URL: https://issues.apache.org/jira/browse/TS-876 Project: Traffic Server Issue Type: New Feature Components: Remap API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 3.1.0 Attachments: TS876.fixed.patch, map_with_recv_port.patch Currently the port in the from fields of all remap rules are compared against the port in the request (explicitly in the request or implicitly deduced from the protocol). TS supports listening on multiple ports, so there is a use case for a remap rule that uses the TS port at which the request is received instead of the request port. -- 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-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-876: Backport to Version: 3.0.3 forward map based on request receive port - Key: TS-876 URL: https://issues.apache.org/jira/browse/TS-876 Project: Traffic Server Issue Type: New Feature Components: Remap API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 3.1.0 Attachments: TS876.fixed.patch, map_with_recv_port.patch Currently the port in the from fields of all remap rules are compared against the port in the request (explicitly in the request or implicitly deduced from the protocol). TS supports listening on multiple ports, so there is a use case for a remap rule that uses the TS port at which the request is received instead of the request port. -- 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-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:all-tabpanel ] Leif Hedstrom updated TS-1094: -- Fix Version/s: 3.1.3 Heh, that's one hell of a bug, 275 bytes exactly, eh? 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 Priority: Blocker Fix For: 3.1.3 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=13195277#comment-13195277 ] Leif Hedstrom commented on TS-1094: --- You don't happen to have a script that reproduces this, do you ? 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 Priority: Blocker Fix For: 3.1.3 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=13195302#comment-13195302 ] Wilson Ho commented on TS-1094: --- What I did was to create a file of URLs ... the same one repeated 512 times. And then use the command : cat url_file | xargs curl -m 25 -H DummyHdr: x -s -S /dev/null The exact URL I used probably won't work for you. You could use the -H flag to create a dummy header to adjust the total header size. The 25 second time out is to force curl to close connection when TS hangs, and generates the error message curl: (28) Operation timed out with 0 out of -1 bytes received This way I could tell easily if TS hangs. The header size must be exact. If my speculation is correct, that's how you end up with a total size of 1 off the 4KB boundary. In theory, there could be many other possible header sizes that could reproduce this problem. But if you look closer, most values of (N x 4096) + 1 don't factorize into nice values within the range of a normal header size. That's why this bug is so hard to reproduce. I'd appreciate if you could point me to the general direction in the source code where request headers are stored/processed. We have a particular application that keeps hitting this bug and I'm eager to patch our code. Or if this bug has been fixed in new releases, please let me know, too! Thanks much! 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 Priority: Blocker Fix For: 3.1.3 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] [Updated] (TS-1095) 3.0.x ts.h.in has incorrect declaration for TSFetchURL
[ https://issues.apache.org/jira/browse/TS-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1095: - Attachment: ts.h.in.patch This patch only applies to the 3.0.x branch. 3.0.x ts.h.in has incorrect declaration for TSFetchURL -- Key: TS-1095 URL: https://issues.apache.org/jira/browse/TS-1095 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.2 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.0.3 Attachments: ts.h.in.patch If you look at the declaration in ts.h.in for TSFetchURL it doesn't match the definition in InkAPI.cc. Patch attached, and updating STATUS file. -- 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-1096) readline support for traffic_shell
readline support for traffic_shell -- Key: TS-1096 URL: https://issues.apache.org/jira/browse/TS-1096 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should use readline to support line editing and command history. -- 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-1097) online help for traffic_shell
online help for traffic_shell - Key: TS-1097 URL: https://issues.apache.org/jira/browse/TS-1097 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should have online help for its commands -- 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-1096) readline support for traffic_shell
[ https://issues.apache.org/jira/browse/TS-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1096: --- Assignee: James Peach readline support for traffic_shell -- Key: TS-1096 URL: https://issues.apache.org/jira/browse/TS-1096 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should use readline to support line editing and command history. -- 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-1097) online help for traffic_shell
[ https://issues.apache.org/jira/browse/TS-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1097: --- Assignee: James Peach online help for traffic_shell - Key: TS-1097 URL: https://issues.apache.org/jira/browse/TS-1097 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should have online help for its commands -- 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-1096) readline support for traffic_shell
[ https://issues.apache.org/jira/browse/TS-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1096. - Resolution: Fixed Committed r1236973 readline support for traffic_shell -- Key: TS-1096 URL: https://issues.apache.org/jira/browse/TS-1096 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should use readline to support line editing and command history. -- 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-1097) online help for traffic_shell
[ https://issues.apache.org/jira/browse/TS-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1097. - Resolution: Fixed Committed r1236974 online help for traffic_shell - Key: TS-1097 URL: https://issues.apache.org/jira/browse/TS-1097 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should have online help for its commands -- 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
