[jira] [Updated] (TS-1631) Clear Stats doesn't work - old value return
[ https://issues.apache.org/jira/browse/TS-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Kopel updated TS-1631: Component/s: (was: Core) Stats Description: I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net thread. 4. RecRawStatSyncCount is called in a loop and summarize all the stats in the net thread to one global value. 5. RecRegisterRawStatSyncCb is called to update the global value in the records table. I'm attaching a patch to fix it. 1. add -z/-Z otipns to traffic_line - to reset specific stat. 2. I added a version variable to the record of the stat - so that if we want to reset a record - we will increase this record. 3. On the next sync to global call (RecExecRawStatSyncCbs in RecProcess.cc) it will clear the sum/counter in the net-tread variables. There is another issue about the RecDecrRawStat function - I'll open on it another Jira. Regards, Yakov Kopel. was: I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net thread. 4. RecRawStatSyncCount is called in a loop and summarize all the stats in the net thread to one global value. 5. RecRegisterRawStatSyncCb is called to update the global value in the records table. I'm attaching a patch to fix it. 1. add -z/-Z otipns to traffic_line - to reset specific stat. 2. I added a version variable to the record of the stat - so that if we want to reset a record - we will increase this record. 3. On the next sync to global call (RecExecRawStatSyncCbs in RecProcess.cc) it will clear the sum/counter in the net-tread variables. There is another issue about the RecDecrRawStat function - I'll open on it another Jira. Regards, Yakov Kopel. Clear Stats doesn't work - old value return --- Key: TS-1631 URL: https://issues.apache.org/jira/browse/TS-1631 Project: Traffic Server Issue Type: Bug Components: Management API, Stats Reporter: Yakov Kopel Attachments: clear_stats_ver_1.diff I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net
[jira] [Updated] (TS-1632) RecDecrRawStat does not seem to work as intended
[ https://issues.apache.org/jira/browse/TS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Kopel updated TS-1632: Description: In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It is similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? was: In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? RecDecrRawStat does not seem to work as intended Key: TS-1632 URL: https://issues.apache.org/jira/browse/TS-1632 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Attachments: dec_stats_sol_1.diff, dec_stats_sol_2.diff In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It is similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537071#comment-13537071 ] Leif Hedstrom commented on TS-1627: --- how does this relate to the SVN bug (TS-871)? I kinda think we ought to support the protocol as specified, which means supporting chunking as well. Support GET requests with payload - Key: TS-1627 URL: https://issues.apache.org/jira/browse/TS-1627 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Uri Shachar Attachments: get_with_payload.patch From what I understand from RFC 2616, these requests should be legal. ATS currently accepts these requests, but drops the body when passing them onward to the upstream. Most discussion that I could find on the web say that this is legal -- although what the upstream can actually do with the payload isn't clear http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html http://tech.groups.yahoo.com/group/rest-discuss/message/9957 http://stackoverflow.com/questions/978061/http-get-with-request-body http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537073#comment-13537073 ] Leif Hedstrom commented on TS-1627: --- What I meant to imply is that TS-871 requires us to support bodies for all methods that don't explicitly excludes it, not just GET and POST :). Support GET requests with payload - Key: TS-1627 URL: https://issues.apache.org/jira/browse/TS-1627 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Uri Shachar Attachments: get_with_payload.patch From what I understand from RFC 2616, these requests should be legal. ATS currently accepts these requests, but drops the body when passing them onward to the upstream. Most discussion that I could find on the web say that this is legal -- although what the upstream can actually do with the payload isn't clear http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html http://tech.groups.yahoo.com/group/rest-discuss/message/9957 http://stackoverflow.com/questions/978061/http-get-with-request-body http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1232: - Assignee: Leif Hedstrom Support unknown methods in HTTP requests Key: TS-1232 URL: https://issues.apache.org/jira/browse/TS-1232 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.3 Reporter: Uri Shachar Assignee: Leif Hedstrom Labels: http Fix For: 3.3.0, 3.2.3 Original Estimate: 72h Remaining Estimate: 72h When acting as a transparent proxy, we may intercept WebDAV and other HTTP based protocols. Currently, the response will be 405 Method Not Allowed even though ATS can deal with the request as long as the rest of it is well-formed. Adding this functionality requires only minor changes and it could be configured on/off (proxy.config.http.accept_unknown_methods) Interested? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1232: -- Assignee: (was: Leif Hedstrom) Support unknown methods in HTTP requests Key: TS-1232 URL: https://issues.apache.org/jira/browse/TS-1232 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.3 Reporter: Uri Shachar Labels: http Fix For: 3.3.0, 3.2.3 Original Estimate: 72h Remaining Estimate: 72h When acting as a transparent proxy, we may intercept WebDAV and other HTTP based protocols. Currently, the response will be 405 Method Not Allowed even though ATS can deal with the request as long as the rest of it is well-formed. Adding this functionality requires only minor changes and it could be configured on/off (proxy.config.http.accept_unknown_methods) Interested? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1631) Clear Stats doesn't work - old value return
[ https://issues.apache.org/jira/browse/TS-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1631: - Assignee: Leif Hedstrom Clear Stats doesn't work - old value return --- Key: TS-1631 URL: https://issues.apache.org/jira/browse/TS-1631 Project: Traffic Server Issue Type: Bug Components: Management API, Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Attachments: clear_stats_ver_1.diff I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net thread. 4. RecRawStatSyncCount is called in a loop and summarize all the stats in the net thread to one global value. 5. RecRegisterRawStatSyncCb is called to update the global value in the records table. I'm attaching a patch to fix it. 1. add -z/-Z otipns to traffic_line - to reset specific stat. 2. I added a version variable to the record of the stat - so that if we want to reset a record - we will increase this record. 3. On the next sync to global call (RecExecRawStatSyncCbs in RecProcess.cc) it will clear the sum/counter in the net-tread variables. There is another issue about the RecDecrRawStat function - I'll open on it another Jira. Regards, Yakov Kopel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1631) Clear Stats doesn't work - old value return
[ https://issues.apache.org/jira/browse/TS-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1631: -- Fix Version/s: 3.3.1 Clear Stats doesn't work - old value return --- Key: TS-1631 URL: https://issues.apache.org/jira/browse/TS-1631 Project: Traffic Server Issue Type: Bug Components: Management API, Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.3.1 Attachments: clear_stats_ver_1.diff I’m trying to clear stats using traffic_line -c/-C and it doesn’t appear to work. After a couple of seconds the old values return. CLI sample output: traffic_line -r proxy.process.http.total_client_connections_ipv4 208 traffic_line -c traffic_line -r proxy.process.http.total_client_connections_ipv4 0 traffic_line -r proxy.process.http.total_client_connections_ipv4 210 I think this is due to not updating the sum/count in the net-threads. When traffic_line -c/-C is called - it clear the records table but not the net-threads sum/count variables. In the next time the RecRawStatSyncCount func will be called it will override the zero value in the records table. For example - http_total_client_connections_ipv4_stat 1. This stat is used in proxy/http/HttpClientSession.cc 2. The macro HTTP_INCREMENT_DYN_STAT using the RecIncrRawStat func to increament the stat value. 3. The RecIncrRawStat increament the sum counter on the specific net thread. 4. RecRawStatSyncCount is called in a loop and summarize all the stats in the net thread to one global value. 5. RecRegisterRawStatSyncCb is called to update the global value in the records table. I'm attaching a patch to fix it. 1. add -z/-Z otipns to traffic_line - to reset specific stat. 2. I added a version variable to the record of the stat - so that if we want to reset a record - we will increase this record. 3. On the next sync to global call (RecExecRawStatSyncCbs in RecProcess.cc) it will clear the sum/counter in the net-tread variables. There is another issue about the RecDecrRawStat function - I'll open on it another Jira. Regards, Yakov Kopel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1632) RecDecrRawStat does not seem to work as intended
[ https://issues.apache.org/jira/browse/TS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1632: - Assignee: Leif Hedstrom RecDecrRawStat does not seem to work as intended Key: TS-1632 URL: https://issues.apache.org/jira/browse/TS-1632 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Attachments: dec_stats_sol_1.diff, dec_stats_sol_2.diff In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It is similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1632) RecDecrRawStat does not seem to work as intended
[ https://issues.apache.org/jira/browse/TS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1632: -- Fix Version/s: 3.3.1 RecDecrRawStat does not seem to work as intended Key: TS-1632 URL: https://issues.apache.org/jira/browse/TS-1632 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Assignee: Leif Hedstrom Fix For: 3.3.1 Attachments: dec_stats_sol_1.diff, dec_stats_sol_2.diff In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that doesn't let the sum value to go beneath the zero value. This can cause to a problem because the sum variable is per net-thread. When the increase is done in one net-thread and the decrease is done in another net-thread - the result will be 1 instead of 0. First solution: remove that patch The problem with the First Solution: If the TS-1631 fix will be in. When the TS will reset the stats, it can cause to not positive values in the sum. this ca be when the reset is done between an increase and decrease. Second solution: remove that patch add a patch on the global sum (RecProcess.cc) and not for each net-thread The problem with the First Solution: It is similar to the problem with the first solution. The different is that it won't show not negative values, but it can show lower value than the real one. anyone can think on a good solution? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537133#comment-13537133 ] Uri Shachar commented on TS-1627: - AFAICT - The only method that is explicitly prohibited from having a body is TRACE -- The code should actually be simpler if I simply switch it to filter based on that I'll take another look and see if I can generate a patch that's clean enough for both this and chunked encoding Support GET requests with payload - Key: TS-1627 URL: https://issues.apache.org/jira/browse/TS-1627 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Uri Shachar Attachments: get_with_payload.patch From what I understand from RFC 2616, these requests should be legal. ATS currently accepts these requests, but drops the body when passing them onward to the upstream. Most discussion that I could find on the web say that this is legal -- although what the upstream can actually do with the payload isn't clear http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html http://tech.groups.yahoo.com/group/rest-discuss/message/9957 http://stackoverflow.com/questions/978061/http-get-with-request-body http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1633) add new stat sync type: TS_STAT_SYNC_MAX
Yakov Kopel created TS-1633: --- Summary: add new stat sync type: TS_STAT_SYNC_MAX Key: TS-1633 URL: https://issues.apache.org/jira/browse/TS-1633 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Adding a new stat sync type - max. This is a good type of stat to find peaks in the stats. It can be very useful with the stat clear api (after the fix - TS-1631). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1633) add new stat sync type: TS_STAT_SYNC_MAX
[ https://issues.apache.org/jira/browse/TS-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Kopel updated TS-1633: Attachment: stat_max_ver_1.diff add new stat sync type: TS_STAT_SYNC_MAX Key: TS-1633 URL: https://issues.apache.org/jira/browse/TS-1633 Project: Traffic Server Issue Type: Bug Components: Stats Reporter: Yakov Kopel Attachments: stat_max_ver_1.diff Adding a new stat sync type - max. This is a good type of stat to find peaks in the stats. It can be very useful with the stat clear api (after the fix - TS-1631). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537227#comment-13537227 ] Leif Hedstrom commented on TS-1627: --- I posted some patches on TS-871 as well, over a year ago, not sure exactly how much I completed... Support GET requests with payload - Key: TS-1627 URL: https://issues.apache.org/jira/browse/TS-1627 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: Uri Shachar Attachments: get_with_payload.patch From what I understand from RFC 2616, these requests should be legal. ATS currently accepts these requests, but drops the body when passing them onward to the upstream. Most discussion that I could find on the web say that this is legal -- although what the upstream can actually do with the payload isn't clear http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html http://tech.groups.yahoo.com/group/rest-discuss/message/9957 http://stackoverflow.com/questions/978061/http-get-with-request-body http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1634) Lua remap plugin crashes on reload
Thach Tran created TS-1634:
--
Summary: Lua remap plugin crashes on reload
Key: TS-1634
URL: https://issues.apache.org/jira/browse/TS-1634
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Thach Tran
To reproduce, one can essentially build TS with Lua support and put a rule in
remap.config indicating using lua.so as plugin.
Next, do a couple of requests to start things off and then touch remap.config
follows by traffic_line -x. It might take a couple of tries but eventually one
will get a crash. The stack trace is typically as follows.
{noformat}
#0 0x2b5a70f6bfd2 in lj_str_new (L=0x209c3d0, str=0x2b5a70d3b079
release, lenx=optimised out) at lj_str.c:123
#1 0x2b5a70f73b97 in lua_getfield (L=0x209c3d0, idx=optimised out,
k=0x2b5a70d3b079 release) at lj_api.c:749
#2 0x2b5a70d35fed in LuaPluginRelease (lua=0x209c3d0) at remap.cc:30
#3 0x2b5a70d362a5 in TSRemapDeleteInstance (ih=0x209c3d0) at remap.cc:80
#4 0x005c6721 in url_mapping::delete_instance (this=0x209b400,
index=0) at UrlMapping.cc:81
#5 0x005c6805 in url_mapping::~url_mapping (this=0x209b400,
__in_chrg=optimised out) at UrlMapping.cc:109
#6 0x005c34b3 in Trieurl_mapping::Clear (this=0x209c5e0) at
../../../lib/ts/Trie.h:213
#7 0x005c2c73 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#8 0x005c2ca6 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#9 0x005c23d2 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:28
#10 0x005c2480 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:30
#11 0x005bc281 in UrlRewrite::_destroyTable (this=0x20aa550,
h_table=0x209b130) at UrlRewrite.cc:630
#12 0x005c1d7a in UrlRewrite::DestroyStore (this=0x20aa550, store=...)
at UrlRewrite.h:124
#13 0x005bbf20 in UrlRewrite::~UrlRewrite (this=0x20aa550,
__in_chrg=optimised out) at UrlRewrite.cc:546
#14 0x0052681f in UR_FreerContinuation::freeEvent (this=0x2aaadc001a20,
event=2, e=0x2aaabc1eb280) at ReverseProxy.cc:168
#15 0x004e366e in Continuation::handleEvent (this=0x2aaadc001a20,
event=2, data=0x2aaabc1eb280) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006e3f9a in EThread::process_event (this=0x2acae010,
e=0x2aaabc1eb280, calling_code=2) at UnixEThread.cc:142
#17 0x006e4332 in EThread::execute (this=0x2acae010) at
UnixEThread.cc:219
#18 0x006e31e2 in spawn_thread_internal (a=0x209b3b0) at Thread.cc:88
#19 0x2b5a611a9e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x2b5a630a3cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x in ?? ()
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1634) Lua remap plugin crashes on reload
[
https://issues.apache.org/jira/browse/TS-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thach Tran updated TS-1634:
---
Affects Version/s: 3.3.4
Lua remap plugin crashes on reload
--
Key: TS-1634
URL: https://issues.apache.org/jira/browse/TS-1634
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.3.4
Reporter: Thach Tran
To reproduce, one can essentially build TS with Lua support and put a rule in
remap.config indicating using lua.so as plugin.
Next, do a couple of requests to start things off and then touch remap.config
follows by traffic_line -x. It might take a couple of tries but eventually
one will get a crash. The stack trace is typically as follows.
{noformat}
#0 0x2b5a70f6bfd2 in lj_str_new (L=0x209c3d0, str=0x2b5a70d3b079
release, lenx=optimised out) at lj_str.c:123
#1 0x2b5a70f73b97 in lua_getfield (L=0x209c3d0, idx=optimised out,
k=0x2b5a70d3b079 release) at lj_api.c:749
#2 0x2b5a70d35fed in LuaPluginRelease (lua=0x209c3d0) at remap.cc:30
#3 0x2b5a70d362a5 in TSRemapDeleteInstance (ih=0x209c3d0) at remap.cc:80
#4 0x005c6721 in url_mapping::delete_instance (this=0x209b400,
index=0) at UrlMapping.cc:81
#5 0x005c6805 in url_mapping::~url_mapping (this=0x209b400,
__in_chrg=optimised out) at UrlMapping.cc:109
#6 0x005c34b3 in Trieurl_mapping::Clear (this=0x209c5e0) at
../../../lib/ts/Trie.h:213
#7 0x005c2c73 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#8 0x005c2ca6 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#9 0x005c23d2 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:28
#10 0x005c2480 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:30
#11 0x005bc281 in UrlRewrite::_destroyTable (this=0x20aa550,
h_table=0x209b130) at UrlRewrite.cc:630
#12 0x005c1d7a in UrlRewrite::DestroyStore (this=0x20aa550,
store=...) at UrlRewrite.h:124
#13 0x005bbf20 in UrlRewrite::~UrlRewrite (this=0x20aa550,
__in_chrg=optimised out) at UrlRewrite.cc:546
#14 0x0052681f in UR_FreerContinuation::freeEvent
(this=0x2aaadc001a20, event=2, e=0x2aaabc1eb280) at ReverseProxy.cc:168
#15 0x004e366e in Continuation::handleEvent (this=0x2aaadc001a20,
event=2, data=0x2aaabc1eb280) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006e3f9a in EThread::process_event (this=0x2acae010,
e=0x2aaabc1eb280, calling_code=2) at UnixEThread.cc:142
#17 0x006e4332 in EThread::execute (this=0x2acae010) at
UnixEThread.cc:219
#18 0x006e31e2 in spawn_thread_internal (a=0x209b3b0) at Thread.cc:88
#19 0x2b5a611a9e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x2b5a630a3cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x in ?? ()
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1634) Lua remap plugin crashes on reload
[
https://issues.apache.org/jira/browse/TS-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537268#comment-13537268
]
Thach Tran commented on TS-1634:
Core file can be downloaded from
https://docs.google.com/open?id=0B7G3SJQXCJ2iRkFOSVYyaEVBSWM
This was generated on linux mint 13 (64 bit).
Lua remap plugin crashes on reload
--
Key: TS-1634
URL: https://issues.apache.org/jira/browse/TS-1634
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.3.4
Reporter: Thach Tran
To reproduce, one can essentially build TS with Lua support and put a rule in
remap.config indicating using lua.so as plugin.
Next, do a couple of requests to start things off and then touch remap.config
follows by traffic_line -x. It might take a couple of tries but eventually
one will get a crash. The stack trace is typically as follows.
{noformat}
#0 0x2b5a70f6bfd2 in lj_str_new (L=0x209c3d0, str=0x2b5a70d3b079
release, lenx=optimised out) at lj_str.c:123
#1 0x2b5a70f73b97 in lua_getfield (L=0x209c3d0, idx=optimised out,
k=0x2b5a70d3b079 release) at lj_api.c:749
#2 0x2b5a70d35fed in LuaPluginRelease (lua=0x209c3d0) at remap.cc:30
#3 0x2b5a70d362a5 in TSRemapDeleteInstance (ih=0x209c3d0) at remap.cc:80
#4 0x005c6721 in url_mapping::delete_instance (this=0x209b400,
index=0) at UrlMapping.cc:81
#5 0x005c6805 in url_mapping::~url_mapping (this=0x209b400,
__in_chrg=optimised out) at UrlMapping.cc:109
#6 0x005c34b3 in Trieurl_mapping::Clear (this=0x209c5e0) at
../../../lib/ts/Trie.h:213
#7 0x005c2c73 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#8 0x005c2ca6 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#9 0x005c23d2 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:28
#10 0x005c2480 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:30
#11 0x005bc281 in UrlRewrite::_destroyTable (this=0x20aa550,
h_table=0x209b130) at UrlRewrite.cc:630
#12 0x005c1d7a in UrlRewrite::DestroyStore (this=0x20aa550,
store=...) at UrlRewrite.h:124
#13 0x005bbf20 in UrlRewrite::~UrlRewrite (this=0x20aa550,
__in_chrg=optimised out) at UrlRewrite.cc:546
#14 0x0052681f in UR_FreerContinuation::freeEvent
(this=0x2aaadc001a20, event=2, e=0x2aaabc1eb280) at ReverseProxy.cc:168
#15 0x004e366e in Continuation::handleEvent (this=0x2aaadc001a20,
event=2, data=0x2aaabc1eb280) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006e3f9a in EThread::process_event (this=0x2acae010,
e=0x2aaabc1eb280, calling_code=2) at UnixEThread.cc:142
#17 0x006e4332 in EThread::execute (this=0x2acae010) at
UnixEThread.cc:219
#18 0x006e31e2 in spawn_thread_internal (a=0x209b3b0) at Thread.cc:88
#19 0x2b5a611a9e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x2b5a630a3cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x in ?? ()
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1634) Lua remap plugin crashes on reload
[
https://issues.apache.org/jira/browse/TS-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537270#comment-13537270
]
Thach Tran commented on TS-1634:
As discussed on irc, this happens because the plugin tries to cast a
LuaPluginState to a lua_State which is wrong.
There's also issues around how to clean up multiple Lua states of multiple
threads as well that will need addressing.
Lua remap plugin crashes on reload
--
Key: TS-1634
URL: https://issues.apache.org/jira/browse/TS-1634
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.3.4
Reporter: Thach Tran
To reproduce, one can essentially build TS with Lua support and put a rule in
remap.config indicating using lua.so as plugin.
Next, do a couple of requests to start things off and then touch remap.config
follows by traffic_line -x. It might take a couple of tries but eventually
one will get a crash. The stack trace is typically as follows.
{noformat}
#0 0x2b5a70f6bfd2 in lj_str_new (L=0x209c3d0, str=0x2b5a70d3b079
release, lenx=optimised out) at lj_str.c:123
#1 0x2b5a70f73b97 in lua_getfield (L=0x209c3d0, idx=optimised out,
k=0x2b5a70d3b079 release) at lj_api.c:749
#2 0x2b5a70d35fed in LuaPluginRelease (lua=0x209c3d0) at remap.cc:30
#3 0x2b5a70d362a5 in TSRemapDeleteInstance (ih=0x209c3d0) at remap.cc:80
#4 0x005c6721 in url_mapping::delete_instance (this=0x209b400,
index=0) at UrlMapping.cc:81
#5 0x005c6805 in url_mapping::~url_mapping (this=0x209b400,
__in_chrg=optimised out) at UrlMapping.cc:109
#6 0x005c34b3 in Trieurl_mapping::Clear (this=0x209c5e0) at
../../../lib/ts/Trie.h:213
#7 0x005c2c73 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#8 0x005c2ca6 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#9 0x005c23d2 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:28
#10 0x005c2480 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:30
#11 0x005bc281 in UrlRewrite::_destroyTable (this=0x20aa550,
h_table=0x209b130) at UrlRewrite.cc:630
#12 0x005c1d7a in UrlRewrite::DestroyStore (this=0x20aa550,
store=...) at UrlRewrite.h:124
#13 0x005bbf20 in UrlRewrite::~UrlRewrite (this=0x20aa550,
__in_chrg=optimised out) at UrlRewrite.cc:546
#14 0x0052681f in UR_FreerContinuation::freeEvent
(this=0x2aaadc001a20, event=2, e=0x2aaabc1eb280) at ReverseProxy.cc:168
#15 0x004e366e in Continuation::handleEvent (this=0x2aaadc001a20,
event=2, data=0x2aaabc1eb280) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006e3f9a in EThread::process_event (this=0x2acae010,
e=0x2aaabc1eb280, calling_code=2) at UnixEThread.cc:142
#17 0x006e4332 in EThread::execute (this=0x2acae010) at
UnixEThread.cc:219
#18 0x006e31e2 in spawn_thread_internal (a=0x209b3b0) at Thread.cc:88
#19 0x2b5a611a9e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x2b5a630a3cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x in ?? ()
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1
evilbandon created TS-1635: -- Summary: url parse BUGS IN Apache Traffic Sever 3.3.1 Key: TS-1635 URL: https://issues.apache.org/jira/browse/TS-1635 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: evilbandon url parse BUGS IN Apache Traffic Sever 3.3.1 the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1634) Lua remap plugin crashes on reload
[
https://issues.apache.org/jira/browse/TS-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-1634:
---
Assignee: James Peach
Lua remap plugin crashes on reload
--
Key: TS-1634
URL: https://issues.apache.org/jira/browse/TS-1634
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.3.4
Reporter: Thach Tran
Assignee: James Peach
To reproduce, one can essentially build TS with Lua support and put a rule in
remap.config indicating using lua.so as plugin.
Next, do a couple of requests to start things off and then touch remap.config
follows by traffic_line -x. It might take a couple of tries but eventually
one will get a crash. The stack trace is typically as follows.
{noformat}
#0 0x2b5a70f6bfd2 in lj_str_new (L=0x209c3d0, str=0x2b5a70d3b079
release, lenx=optimised out) at lj_str.c:123
#1 0x2b5a70f73b97 in lua_getfield (L=0x209c3d0, idx=optimised out,
k=0x2b5a70d3b079 release) at lj_api.c:749
#2 0x2b5a70d35fed in LuaPluginRelease (lua=0x209c3d0) at remap.cc:30
#3 0x2b5a70d362a5 in TSRemapDeleteInstance (ih=0x209c3d0) at remap.cc:80
#4 0x005c6721 in url_mapping::delete_instance (this=0x209b400,
index=0) at UrlMapping.cc:81
#5 0x005c6805 in url_mapping::~url_mapping (this=0x209b400,
__in_chrg=optimised out) at UrlMapping.cc:109
#6 0x005c34b3 in Trieurl_mapping::Clear (this=0x209c5e0) at
../../../lib/ts/Trie.h:213
#7 0x005c2c73 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#8 0x005c2ca6 in Trieurl_mapping::~Trie (this=0x209c5e0,
__in_chrg=optimised out) at ../../../lib/ts/Trie.h:54
#9 0x005c23d2 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:28
#10 0x005c2480 in UrlMappingPathIndex::~UrlMappingPathIndex
(this=0x209c5a0, __in_chrg=optimised out) at UrlMappingPathIndex.cc:30
#11 0x005bc281 in UrlRewrite::_destroyTable (this=0x20aa550,
h_table=0x209b130) at UrlRewrite.cc:630
#12 0x005c1d7a in UrlRewrite::DestroyStore (this=0x20aa550,
store=...) at UrlRewrite.h:124
#13 0x005bbf20 in UrlRewrite::~UrlRewrite (this=0x20aa550,
__in_chrg=optimised out) at UrlRewrite.cc:546
#14 0x0052681f in UR_FreerContinuation::freeEvent
(this=0x2aaadc001a20, event=2, e=0x2aaabc1eb280) at ReverseProxy.cc:168
#15 0x004e366e in Continuation::handleEvent (this=0x2aaadc001a20,
event=2, data=0x2aaabc1eb280) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x006e3f9a in EThread::process_event (this=0x2acae010,
e=0x2aaabc1eb280, calling_code=2) at UnixEThread.cc:142
#17 0x006e4332 in EThread::execute (this=0x2acae010) at
UnixEThread.cc:219
#18 0x006e31e2 in spawn_thread_internal (a=0x209b3b0) at Thread.cc:88
#19 0x2b5a611a9e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#20 0x2b5a630a3cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x in ?? ()
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
