[jira] [Commented] (TS-4724) Adding/creating new lua APIs: "ts.server_request.set_url_host", "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and "ts.server_request.get_url_scheme
[ https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15632727#comment-15632727 ] Rajendra Kishore Bonumahanti commented on TS-4724: -- Submitted PR #1183 > Adding/creating new lua APIs: "ts.server_request.set_url_host", > "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and > "ts.server_request.get_url_scheme " > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > Fix For: 7.0.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > Create new lua APIs "ts.server_request.set_url_host", > "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and > "ts.server_request.get_url_scheme " to Set/Get scheme and host name in the > server request to next tier. > These APIs are useful to remove scheme and host name in the request to > parent, which help to have a parent remap.config entry similar to child > cache. This makes provisioning more meaningful and easy at both parent and > child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)
[
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15632722#comment-15632722
]
Rajendra Kishore Bonumahanti commented on TS-4911:
--
I submitted PR #1182
> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 7.0.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
> restarted due to “FATAL: InkAPI.cc:3800: failed assert
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
> was encountered (thundering herd problem). The ATS restart is due to
> ts.client_response.get_status() function call in
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
>
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj)
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false,
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
> Reverse Proxy is On
> Forward Mapping Table with 3 entries
> http:/// => http://127.0.0.1/ <> [plugins not enabled; running with
> 0 plugins]
> http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
> running with plugins]
> http://testurl.com/ => http://origin.com// <> [plugins are enabled;
> running with 2 plugins]
> Reverse Mapping Table with 0 entries
> Permanent Redirect Mapping Table with 0 entries
> Temporary Redirect Mapping Table with 0 entries
> Forward Mapping With Recv Port Table with 0 entries
> Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
>
[jira] [Commented] (TS-4724) Adding/creating new lua APIs: "ts.server_request.set_url_host", "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and "ts.server_request.get_url_scheme
[ https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15630088#comment-15630088 ] Rajendra Kishore Bonumahanti commented on TS-4724: -- I will do it. > Adding/creating new lua APIs: "ts.server_request.set_url_host", > "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and > "ts.server_request.get_url_scheme " > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > Fix For: 7.0.0 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Create new lua APIs "ts.server_request.set_url_host", > "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and > "ts.server_request.get_url_scheme " to Set/Get scheme and host name in the > server request to next tier. > These APIs are useful to remove scheme and host name in the request to > parent, which help to have a parent remap.config entry similar to child > cache. This makes provisioning more meaningful and easy at both parent and > child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)
[
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15629764#comment-15629764
]
Rajendra Kishore Bonumahanti commented on TS-4911:
--
Hi Phil, I will do it.
> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 7.0.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
> restarted due to “FATAL: InkAPI.cc:3800: failed assert
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
> was encountered (thundering herd problem). The ATS restart is due to
> ts.client_response.get_status() function call in
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
>
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj)
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false,
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
> Reverse Proxy is On
> Forward Mapping Table with 3 entries
> http:/// => http://127.0.0.1/ <> [plugins not enabled; running with
> 0 plugins]
> http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
> running with plugins]
> http://testurl.com/ => http://origin.com// <> [plugins are enabled;
> running with 2 plugins]
> Reverse Mapping Table with 0 entries
> Permanent Redirect Mapping Table with 0 entries
> Temporary Redirect Mapping Table with 0 entries
> Forward Mapping With Recv Port Table with 0 entries
> Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
>
[jira] [Updated] (TS-4911) ts_lua restarts ATS when it is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem).
[
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajendra Kishore Bonumahanti updated TS-4911:
-
Summary: ts_lua restarts ATS when it is used with collapsed_forwarding
plugin and write lock error was encountered (thundering herd problem). (was:
ts_lua rebtarts ATS when it is used with collapsed_forwarding plugin and write
lock error was encountered (thundering herd problem). )
> ts_lua restarts ATS when it is used with collapsed_forwarding plugin and
> write lock error was encountered (thundering herd problem).
> -
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Plugins
>Reporter: Rajendra Kishore Bonumahanti
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
> restarted due to “FATAL: InkAPI.cc:3800: failed assert
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
> was encountered (thundering herd problem). The ATS restart is due to
> ts.client_response.get_status() function call in
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
>
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj)
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false,
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
> Reverse Proxy is On
> Forward Mapping Table with 3 entries
> http:/// => http://127.0.0.1/ <> [plugins not enabled; running with
> 0 plugins]
> http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
> running with plugins]
> http://testurl.com/ => http://origin.com// <> [plugins are enabled;
> running with 2 plugins]
> Reverse Mapping Table with 0 entries
> Permanent Redirect Mapping Table with 0 entries
> Temporary Redirect Mapping Table with 0 entries
> Forward Mapping With Recv Port Table with 0 entries
> Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
>
[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)
[
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajendra Kishore Bonumahanti updated TS-4911:
-
Fix Version/s: 7.1.0
7.0.0
6.2.1
> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
> restarted due to “FATAL: InkAPI.cc:3800: failed assert
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
> was encountered (thundering herd problem). The ATS restart is due to
> ts.client_response.get_status() function call in
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
>
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj)
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false,
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
> Reverse Proxy is On
> Forward Mapping Table with 3 entries
> http:/// => http://127.0.0.1/ <> [plugins not enabled; running with
> 0 plugins]
> http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
> running with plugins]
> http://testurl.com/ => http://origin.com// <> [plugins are enabled;
> running with 2 plugins]
> Reverse Mapping Table with 0 entries
> Permanent Redirect Mapping Table with 0 entries
> Temporary Redirect Mapping Table with 0 entries
> Forward Mapping With Recv Port Table with 0 entries
> Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
>
> It appears, the following code in ts_lua
[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)
[
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajendra Kishore Bonumahanti updated TS-4911:
-
Affects Version/s: 7.1.0
7.0.0
6.2.1
> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 6.2.1, 7.0.0, 7.1.0
>
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
> restarted due to “FATAL: InkAPI.cc:3800: failed assert
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
> was encountered (thundering herd problem). The ATS restart is due to
> ts.client_response.get_status() function call in
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
>
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj)
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false,
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
> Reverse Proxy is On
> Forward Mapping Table with 3 entries
> http:/// => http://127.0.0.1/ <> [plugins not enabled; running with
> 0 plugins]
> http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
> running with plugins]
> http://testurl.com/ => http://origin.com// <> [plugins are enabled;
> running with 2 plugins]
> Reverse Mapping Table with 0 entries
> Permanent Redirect Mapping Table with 0 entries
> Temporary Redirect Mapping Table with 0 entries
> Forward Mapping With Recv Port Table with 0 entries
> Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
>
> It appears, the following code
[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)
[
https://issues.apache.org/jira/browse/TS-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajendra Kishore Bonumahanti updated TS-4911:
-
Summary: ATS restarts when ts_lua plugin is used with collapsed_forwarding
plugin and write lock error was encountered (thundering herd problem) (was:
ts_lua restarts ATS when it is used with collapsed_forwarding plugin and write
lock error was encountered (thundering herd problem). )
> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Plugins
>Reporter: Rajendra Kishore Bonumahanti
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
> restarted due to “FATAL: InkAPI.cc:3800: failed assert
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
> was encountered (thundering herd problem). The ATS restart is due to
> ts.client_response.get_status() function call in
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
>
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj)
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false,
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
> Reverse Proxy is On
> Forward Mapping Table with 3 entries
> http:/// => http://127.0.0.1/ <> [plugins not enabled; running with
> 0 plugins]
> http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
> running with plugins]
> http://testurl.com/ => http://origin.com// <> [plugins are enabled;
> running with 2 plugins]
> Reverse Mapping Table with 0 entries
> Permanent Redirect Mapping Table with 0 entries
> Temporary Redirect Mapping Table with 0 entries
> Forward Mapping With Recv Port Table with 0 entries
> Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
>
[jira] [Created] (TS-4911) ts_lua rebtarts ATS when it is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem).
Rajendra Kishore Bonumahanti created TS-4911:
Summary: ts_lua rebtarts ATS when it is used with
collapsed_forwarding plugin and write lock error was encountered (thundering
herd problem).
Key: TS-4911
URL: https://issues.apache.org/jira/browse/TS-4911
Project: Traffic Server
Issue Type: Bug
Components: Lua, Plugins
Reporter: Rajendra Kishore Bonumahanti
ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got
restarted due to “FATAL: InkAPI.cc:3800: failed assert
`sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error
was encountered (thundering herd problem). The ATS restart is due to
ts.client_response.get_status() function call in TS_LUA_HOOK_SEND_RESPONSE_HDR
hook function when re-direct is enabled on 502 error.
== error when ts_lua plugin is used with collapsed_forwarding plugin ==
map http://testurl.com/ http://origin.com/ @plugin=tslua.so
@pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
@plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
test.lua:
===
function __init__()
local FUNCTION = '__init__(): '
ts.debug(FUNCTION .. 'Entering..')
return 0
end
function responseHook()
local FUNCTION = 'responseHook(): '
ts.debug(FUNCTION .. 'Entering..')
local c_code = tostring(ts.client_response.get_status())
ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
if string.find(c_code, "^[45]") then
ts.debug(FUNCTION .. 'client response code is now set to 500')
ts.client_response.set_status(500)
end
return 0
end
function do_remap()
local FUNCTION = 'do_remap(): '
ts.debug(FUNCTION .. 'Entering..')
ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
return 0
end
The log…
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State
Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148]
perform_cache_write_action CACE_DO_SERVE
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect)
is_redirect_required 1
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling
plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
[Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook():
Entering..
FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) ==
TS_SUCCESS`
traffic_server: using root directory '/opt/trafficserver'
validate_filter_args: "action=deny"
-
Filter "" status: allow_flag=false, src_ip_valid=false,
in_ip_valid=false, internal=false active_queue_flag=0
standard methods=nonstandard methods=
src_ip_cnt=0
in_ip_cnt=0
URL Rewrite table with 3 entries
Reverse Proxy is On
Forward Mapping Table with 3 entries
http:/// => http://127.0.0.1/ <> [plugins not enabled; running with 0
plugins]
http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/ <> [plugins are enabled;
running with plugins]
http://testurl.com/ => http://origin.com// <> [plugins are enabled;
running with 2 plugins]
Reverse Mapping Table with 0 entries
Permanent Redirect Mapping Table with 0 entries
Temporary Redirect Mapping Table with 0 entries
Forward Mapping With Recv Port Table with 0 entries
Referer filter default redirect URL: "http://www.example.com/;
traffic_server: Aborted (Signal sent by tkill() 129399 99)
traffic_server - STACK TRACE:
/opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
/lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
/lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
/lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
/opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
/opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
/opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
/opt/trafficserver/bin/traffic_server[0x4c7973]
/opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
/opt/trafficserver/bin/traffic_server[0x5834e6]
It appears, the following code in ts_lua [ts_lua_client_response.c] plugin
causes the sdk_sanity check failed.
#define TS_LUA_CHECK_CLIENT_RESPONSE_HDR(http_ctx)
\
do {
\
if (!http_ctx->client_response_hdrp) {
\
if (TSHttpTxnClientRespGet(http_ctx->txnp,
_ctx->client_response_bufp, _ctx->client_response_hdrp) != \
TS_SUCCESS) {
[jira] [Updated] (TS-4888) collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not perform remap
[
https://issues.apache.org/jira/browse/TS-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajendra Kishore Bonumahanti updated TS-4888:
-
Fix Version/s: 7.1.0
6.2.1
> collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not
> perform remap
> -
>
> Key: TS-4888
> URL: https://issues.apache.org/jira/browse/TS-4888
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.2.1, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 6.2.1, 7.1.0
>
>
> Collapsed_forwarding plugin returns TSREMAP_DID_REMAP as a return value
> though it did not perform any remap. This causes ATS not to perform remap and
> makes the transaction failed due to DNS lookup error on "from url".
> For more details..
> Hi,
> I am testing collapsed_forwarding plugin
> (https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/collapsed_forwarding.en.html?highlight=collapsed_forwarding)
> via ATS 6.2.x branch.
> We observed an error "DNS error 2 for [testurl.com]" for cache-miss, when
> remap.config is configured with "collapsed_forwarding" to work alone as a
> remap plugin. We must modify TSRemapDoRemap() in the plugin to "return
> TSREMAP_NO_REMAP" to allow DNS lookup successful. It does not seem right for
> the plugin to do "return TSREMAP_NO_REMAP" when it did not.
> Can someone help me to understand how this plugin needs to be used? Or does
> it require the fix I mentioned above?
> Regards,
> Kishore
> == Sample remap.config entry and cach miss error when used
> "collapsed_forwarding" by itself == map http://testurl.com/
> http://origin.com/ @plugin=collapsed_forwarding.so @pparam=--delay=10
> @pparam=--retries=5
> I observed that during cache-miss, DNS query happens on the 'from' url
> (hostname) in the remap and it gets failed.
>
> [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) send query
> (qtype=1) for testurl.com to fd 43 [Sep 9 19:39:16.355] Server
> {0x2b170ea6c940} DEBUG: (dns) sent qname = testurl.com, id = 9287, nameserver
> = 1 [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) sent_one:
> failover_number for resolve 1 is 1 [Sep 9 19:39:16.628] Server
> {0x2b170ea6c940} DEBUG: (dns) received packet size = 52 [Sep 9 19:39:16.628]
> Server {0x2b170ea6c940} DEBUG: (dns) round-robin: nameserver 1 DNS respons
> code = 0 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) received
> rcode = 2 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) DNS
> error 2 for [testurl.com] [Sep 9 19:39:16.628] Server {0x2b170ea6c940}
> DEBUG: (dns) doing retry for testurl.com
> I further looked in to the code and found that it is due to return code from
> the plugin is TSREMAP_DID_REMAP in TSRemapDoRemap(). It makes ATS not to
> perform remap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4888) collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not perform remap
[
https://issues.apache.org/jira/browse/TS-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15514074#comment-15514074
]
Rajendra Kishore Bonumahanti commented on TS-4888:
--
I will be working on the PR.
> collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not
> perform remap
> -
>
> Key: TS-4888
> URL: https://issues.apache.org/jira/browse/TS-4888
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.2.1, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>
> Collapsed_forwarding plugin returns TSREMAP_DID_REMAP as a return value
> though it did not perform any remap. This causes ATS not to perform remap and
> makes the transaction failed due to DNS lookup error on "from url".
> For more details..
> Hi,
> I am testing collapsed_forwarding plugin
> (https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/collapsed_forwarding.en.html?highlight=collapsed_forwarding)
> via ATS 6.2.x branch.
> We observed an error "DNS error 2 for [testurl.com]" for cache-miss, when
> remap.config is configured with "collapsed_forwarding" to work alone as a
> remap plugin. We must modify TSRemapDoRemap() in the plugin to "return
> TSREMAP_NO_REMAP" to allow DNS lookup successful. It does not seem right for
> the plugin to do "return TSREMAP_NO_REMAP" when it did not.
> Can someone help me to understand how this plugin needs to be used? Or does
> it require the fix I mentioned above?
> Regards,
> Kishore
> == Sample remap.config entry and cach miss error when used
> "collapsed_forwarding" by itself == map http://testurl.com/
> http://origin.com/ @plugin=collapsed_forwarding.so @pparam=--delay=10
> @pparam=--retries=5
> I observed that during cache-miss, DNS query happens on the 'from' url
> (hostname) in the remap and it gets failed.
>
> [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) send query
> (qtype=1) for testurl.com to fd 43 [Sep 9 19:39:16.355] Server
> {0x2b170ea6c940} DEBUG: (dns) sent qname = testurl.com, id = 9287, nameserver
> = 1 [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) sent_one:
> failover_number for resolve 1 is 1 [Sep 9 19:39:16.628] Server
> {0x2b170ea6c940} DEBUG: (dns) received packet size = 52 [Sep 9 19:39:16.628]
> Server {0x2b170ea6c940} DEBUG: (dns) round-robin: nameserver 1 DNS respons
> code = 0 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) received
> rcode = 2 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) DNS
> error 2 for [testurl.com] [Sep 9 19:39:16.628] Server {0x2b170ea6c940}
> DEBUG: (dns) doing retry for testurl.com
> I further looked in to the code and found that it is due to return code from
> the plugin is TSREMAP_DID_REMAP in TSRemapDoRemap(). It makes ATS not to
> perform remap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4888) collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not perform remap
[
https://issues.apache.org/jira/browse/TS-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajendra Kishore Bonumahanti updated TS-4888:
-
Affects Version/s: 7.1.0
6.2.1
> collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not
> perform remap
> -
>
> Key: TS-4888
> URL: https://issues.apache.org/jira/browse/TS-4888
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.2.1, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>
> Collapsed_forwarding plugin returns TSREMAP_DID_REMAP as a return value
> though it did not perform any remap. This causes ATS not to perform remap and
> makes the transaction failed due to DNS lookup error on "from url".
> For more details..
> Hi,
> I am testing collapsed_forwarding plugin
> (https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/collapsed_forwarding.en.html?highlight=collapsed_forwarding)
> via ATS 6.2.x branch.
> We observed an error "DNS error 2 for [testurl.com]" for cache-miss, when
> remap.config is configured with "collapsed_forwarding" to work alone as a
> remap plugin. We must modify TSRemapDoRemap() in the plugin to "return
> TSREMAP_NO_REMAP" to allow DNS lookup successful. It does not seem right for
> the plugin to do "return TSREMAP_NO_REMAP" when it did not.
> Can someone help me to understand how this plugin needs to be used? Or does
> it require the fix I mentioned above?
> Regards,
> Kishore
> == Sample remap.config entry and cach miss error when used
> "collapsed_forwarding" by itself == map http://testurl.com/
> http://origin.com/ @plugin=collapsed_forwarding.so @pparam=--delay=10
> @pparam=--retries=5
> I observed that during cache-miss, DNS query happens on the 'from' url
> (hostname) in the remap and it gets failed.
>
> [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) send query
> (qtype=1) for testurl.com to fd 43 [Sep 9 19:39:16.355] Server
> {0x2b170ea6c940} DEBUG: (dns) sent qname = testurl.com, id = 9287, nameserver
> = 1 [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) sent_one:
> failover_number for resolve 1 is 1 [Sep 9 19:39:16.628] Server
> {0x2b170ea6c940} DEBUG: (dns) received packet size = 52 [Sep 9 19:39:16.628]
> Server {0x2b170ea6c940} DEBUG: (dns) round-robin: nameserver 1 DNS respons
> code = 0 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) received
> rcode = 2 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) DNS
> error 2 for [testurl.com] [Sep 9 19:39:16.628] Server {0x2b170ea6c940}
> DEBUG: (dns) doing retry for testurl.com
> I further looked in to the code and found that it is due to return code from
> the plugin is TSREMAP_DID_REMAP in TSRemapDoRemap(). It makes ATS not to
> perform remap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4888) collapsed_forwarding plugin returns TSREMAP_DID_REMAP though it did not perform remap
Rajendra Kishore Bonumahanti created TS-4888:
Summary: collapsed_forwarding plugin returns TSREMAP_DID_REMAP
though it did not perform remap
Key: TS-4888
URL: https://issues.apache.org/jira/browse/TS-4888
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Rajendra Kishore Bonumahanti
Collapsed_forwarding plugin returns TSREMAP_DID_REMAP as a return value though
it did not perform any remap. This causes ATS not to perform remap and makes
the transaction failed due to DNS lookup error on "from url".
For more details..
Hi,
I am testing collapsed_forwarding plugin
(https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/collapsed_forwarding.en.html?highlight=collapsed_forwarding)
via ATS 6.2.x branch.
We observed an error "DNS error 2 for [testurl.com]" for cache-miss, when
remap.config is configured with "collapsed_forwarding" to work alone as a remap
plugin. We must modify TSRemapDoRemap() in the plugin to "return
TSREMAP_NO_REMAP" to allow DNS lookup successful. It does not seem right for
the plugin to do "return TSREMAP_NO_REMAP" when it did not.
Can someone help me to understand how this plugin needs to be used? Or does it
require the fix I mentioned above?
Regards,
Kishore
== Sample remap.config entry and cach miss error when used
"collapsed_forwarding" by itself == map http://testurl.com/ http://origin.com/
@plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
I observed that during cache-miss, DNS query happens on the 'from' url
(hostname) in the remap and it gets failed.
[Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG: (dns) send query (qtype=1)
for testurl.com to fd 43 [Sep 9 19:39:16.355] Server {0x2b170ea6c940} DEBUG:
(dns) sent qname = testurl.com, id = 9287, nameserver = 1 [Sep 9 19:39:16.355]
Server {0x2b170ea6c940} DEBUG: (dns) sent_one: failover_number for resolve 1 is
1 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) received packet
size = 52 [Sep 9 19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns)
round-robin: nameserver 1 DNS respons code = 0 [Sep 9 19:39:16.628] Server
{0x2b170ea6c940} DEBUG: (dns) received rcode = 2 [Sep 9 19:39:16.628] Server
{0x2b170ea6c940} DEBUG: (dns) DNS error 2 for [testurl.com] [Sep 9
19:39:16.628] Server {0x2b170ea6c940} DEBUG: (dns) doing retry for testurl.com
I further looked in to the code and found that it is due to return code from
the plugin is TSREMAP_DID_REMAP in TSRemapDoRemap(). It makes ATS not to
perform remap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4724) Adding/creating new lua APIs: "ts.server_request.set_url_host", "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and "ts.server_request.get_url_scheme "
[ https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajendra Kishore Bonumahanti updated TS-4724: - Description: Create new lua APIs "ts.server_request.set_url_host", "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and "ts.server_request.get_url_scheme " to Set/Get scheme and host name in the server request to next tier. These APIs are useful to remove scheme and host name in the request to parent, which help to have a parent remap.config entry similar to child cache. This makes provisioning more meaningful and easy at both parent and child. With this fix, the GET request to parent will change.. from: + Proxy's Request + -- State Machine Id: 5593 GET http://origin.com/dir1/a.txt HTTP/1.1^M User-Agent: curl/7.29.0^M Host: abc.com^M Accept: */*^M Client-ip: 135.xx.xx.xx^M X-Forwarded-For: 135.xx.xx.xx^M To: + Proxy's Request + -- State Machine Id: 5593 GET /dir1/a.txt HTTP/1.1^M User-Agent: curl/7.29.0^M Host: abc.com^M Accept: */*^M Client-ip: 135.xx.xx.xx^M X-Forwarded-For: 135.xx.xx.xx^M This will enable to have parent and child's remap.config entries as below: map http://abc.com http://origin.com @plugin=tslua.so @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua was: Create a new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request to next tier. This helps to have a parent remap.config entry similar to child cache. This makes provisioning more meaningful and easy at both parent and child. With this fix, the GET request to parent will change.. from: + Proxy's Request + -- State Machine Id: 5593 GET http://origin.com/dir1/a.txt HTTP/1.1^M User-Agent: curl/7.29.0^M Host: abc.com^M Accept: */*^M Client-ip: 135.xx.xx.xx^M X-Forwarded-For: 135.xx.xx.xx^M To: + Proxy's Request + -- State Machine Id: 5593 GET /dir1/a.txt HTTP/1.1^M User-Agent: curl/7.29.0^M Host: abc.com^M Accept: */*^M Client-ip: 135.xx.xx.xx^M X-Forwarded-For: 135.xx.xx.xx^M This will enable to have parent and child's remap.config entries as below: map http://abc.com http://origin.com @plugin=tslua.so @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua Summary: Adding/creating new lua APIs: "ts.server_request.set_url_host", "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and "ts.server_request.get_url_scheme " (was: Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier) > Adding/creating new lua APIs: "ts.server_request.set_url_host", > "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and > "ts.server_request.get_url_scheme " > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > Fix For: 7.0.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Create new lua APIs "ts.server_request.set_url_host", > "ts.server_request.get_url_host", "ts.server_request.set_url_scheme", and > "ts.server_request.get_url_scheme " to Set/Get scheme and host name in the > server request to next tier. > These APIs are useful to remove scheme and host name in the request to > parent, which help to have a parent remap.config entry similar to child > cache. This makes provisioning more meaningful and easy at both parent and > child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
[
https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414178#comment-15414178
]
Rajendra Kishore Bonumahanti edited comment on TS-4724 at 8/9/16 8:26 PM:
--
The existing ts_lua API, ts.server_request.set_uri(), will help to modify the
URI. It does not help to remove the hostname from URL. I tested it.
ts.server_request.set_uri("/dir2/a.txt") will make the GET request
(http://abc.com/dir1/a.txt) as below..
+ Proxy's Request +
-- State Machine Id: 5593
GET http://origin.com/dir2/a.txt HTTP/1.1^M
User-Agent: curl/7.29.0^M
Host: abc.com^M
Accept: */*^M
Client-ip: 135.xx.xx.xx^M
X-Forwarded-For: 135.xx.xx.xx^M
I will work on the pull request..
was (Author: rkishore):
The existing ts_lua API, ts.server_request.set_uri(), will help to modify the
URI. It does not help to remove the hostname from URL. I tested it.
ts.server_request.set_uri("/dir2/a.txt") will make the GET request
(http://abc.com/dir1/a.txt)as below..
+ Proxy's Request +
-- State Machine Id: 5593
GET http://origin.com/dir2/a.txt HTTP/1.1^M
User-Agent: curl/7.29.0^M
Host: abc.com^M
Accept: */*^M
Client-ip: 135.xx.xx.xx^M
X-Forwarded-For: 135.xx.xx.xx^M
> Adding/creating new lua API "ts.server_request.remove_host_name_from_url()"
> to remove host name from the GET request send to next tier
> --
>
> Key: TS-4724
> URL: https://issues.apache.org/jira/browse/TS-4724
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 7.0.0
>
>
> Create a new lua API "ts.server_request.remove_host_name_from_url()" to
> remove host name from the GET request to next tier. This helps to have a
> parent remap.config entry similar to child cache. This makes provisioning
> more meaningful and easy at both parent and child.
> With this fix, the GET request to parent will change..
> from:
> + Proxy's Request +
> -- State Machine Id: 5593
> GET http://origin.com/dir1/a.txt HTTP/1.1^M
> User-Agent: curl/7.29.0^M
> Host: abc.com^M
> Accept: */*^M
> Client-ip: 135.xx.xx.xx^M
> X-Forwarded-For: 135.xx.xx.xx^M
> To:
> + Proxy's Request +
> -- State Machine Id: 5593
> GET /dir1/a.txt HTTP/1.1^M
> User-Agent: curl/7.29.0^M
> Host: abc.com^M
> Accept: */*^M
> Client-ip: 135.xx.xx.xx^M
> X-Forwarded-For: 135.xx.xx.xx^M
> This will enable to have parent and child's remap.config entries as below:
> map http://abc.com http://origin.com @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
[
https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15414178#comment-15414178
]
Rajendra Kishore Bonumahanti commented on TS-4724:
--
The existing ts_lua API, ts.server_request.set_uri(), will help to modify the
URI. It does not help to remove the hostname from URL. I tested it.
ts.server_request.set_uri("/dir2/a.txt") will make the GET request
(http://abc.com/dir1/a.txt)as below..
+ Proxy's Request +
-- State Machine Id: 5593
GET http://origin.com/dir2/a.txt HTTP/1.1^M
User-Agent: curl/7.29.0^M
Host: abc.com^M
Accept: */*^M
Client-ip: 135.xx.xx.xx^M
X-Forwarded-For: 135.xx.xx.xx^M
> Adding/creating new lua API "ts.server_request.remove_host_name_from_url()"
> to remove host name from the GET request send to next tier
> --
>
> Key: TS-4724
> URL: https://issues.apache.org/jira/browse/TS-4724
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Reporter: Rajendra Kishore Bonumahanti
> Fix For: 7.0.0
>
>
> Create a new lua API "ts.server_request.remove_host_name_from_url()" to
> remove host name from the GET request to next tier. This helps to have a
> parent remap.config entry similar to child cache. This makes provisioning
> more meaningful and easy at both parent and child.
> With this fix, the GET request to parent will change..
> from:
> + Proxy's Request +
> -- State Machine Id: 5593
> GET http://origin.com/dir1/a.txt HTTP/1.1^M
> User-Agent: curl/7.29.0^M
> Host: abc.com^M
> Accept: */*^M
> Client-ip: 135.xx.xx.xx^M
> X-Forwarded-For: 135.xx.xx.xx^M
> To:
> + Proxy's Request +
> -- State Machine Id: 5593
> GET /dir1/a.txt HTTP/1.1^M
> User-Agent: curl/7.29.0^M
> Host: abc.com^M
> Accept: */*^M
> Client-ip: 135.xx.xx.xx^M
> X-Forwarded-For: 135.xx.xx.xx^M
> This will enable to have parent and child's remap.config entries as below:
> map http://abc.com http://origin.com @plugin=tslua.so
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
[ https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15412422#comment-15412422 ] Rajendra Kishore Bonumahanti commented on TS-4724: -- Kit, if there is a way with the existing ts_lua APIs, I would like to try first. Could you please give some hints, with which I will look around. > Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" > to remove host name from the GET request send to next tier > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > > Create a new lua API "ts.server_request.remove_host_name_from_url()" to > remove host name from the GET request to next tier. This helps to have a > parent remap.config entry similar to child cache. This makes provisioning > more meaningful and easy at both parent and child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
[ https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411891#comment-15411891 ] Rajendra Kishore Bonumahanti commented on TS-4724: -- This TS_LUA plugin enhancement to provide a new API to remove host name from GET request. Request Kit review and assign it to me. I can submit pull request. > Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" > to remove host name from the GET request send to next tier > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > > Create a new lua API "ts.server_request.remove_host_name_from_url()" to > remove host name from the GET request to next tier. This helps to have a > parent remap.config entry similar to child cache. This makes provisioning > more meaningful and easy at both parent and child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
[ https://issues.apache.org/jira/browse/TS-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411891#comment-15411891 ] Rajendra Kishore Bonumahanti edited comment on TS-4724 at 8/8/16 2:41 PM: -- This TS_LUA plugin enhancement to provide a new API to remove host name from GET request. Request Kit to review my proposal and assign it to me. I can submit pull request. was (Author: rkishore): This TS_LUA plugin enhancement to provide a new API to remove host name from GET request. Request Kit review and assign it to me. I can submit pull request. > Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" > to remove host name from the GET request send to next tier > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > > Create a new lua API "ts.server_request.remove_host_name_from_url()" to > remove host name from the GET request to next tier. This helps to have a > parent remap.config entry similar to child cache. This makes provisioning > more meaningful and easy at both parent and child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
Rajendra Kishore Bonumahanti created TS-4724: Summary: Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier Key: TS-4724 URL: https://issues.apache.org/jira/browse/TS-4724 Project: Traffic Server Issue Type: Improvement Components: Lua Reporter: Rajendra Kishore Bonumahanti Create a new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request to next tier. This helps to have a parent remap.config entry similar to child cache. This makes provisioning more meaningful and easy at both parent and child. With this fix, the GET request to parent will change.. from: + Proxy's Request + -- State Machine Id: 5593 GET http://origin.com/dir1/a.txt HTTP/1.1^M User-Agent: curl/7.29.0^M Host: abc.com^M Accept: */*^M Client-ip: 135.xx.xx.xx^M X-Forwarded-For: 135.xx.xx.xx^M To: + Proxy's Request + -- State Machine Id: 5593 GET /dir1/a.txt HTTP/1.1^M User-Agent: curl/7.29.0^M Host: abc.com^M Accept: */*^M Client-ip: 135.xx.xx.xx^M X-Forwarded-For: 135.xx.xx.xx^M This will enable to have parent and child's remap.config entries as below: map http://abc.com http://origin.com @plugin=tslua.so @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4266) ATS memory statistics shows that memory utilization is doubled after “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
[
https://issues.apache.org/jira/browse/TS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15207376#comment-15207376
]
Rajendra Kishore Bonumahanti commented on TS-4266:
--
Kit: I created a new pull request with help from Peter.
https://github.com/apache/trafficserver/pull/532
Please review and merge.
> ATS memory statistics shows that memory utilization is doubled after
> “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
> --
>
> Key: TS-4266
> URL: https://issues.apache.org/jira/browse/TS-4266
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: sometime
>
>
> ATS memory statistics shows memory utilization is doubled after “traffic_ctl
> config reload”. We get “not enough memory” error in the subsequent attempt
> and “config reload” fails.
> ATS is configured with 100 map entries in remap.config, all share the same
> lua script.
> ATS is started: The memory information is..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1416092 670256 663736
> After 1st Config reload:
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1932660 1128084 1121544
> After 2nd config reload: It had failed with error “not enough memory” and
> memory status as..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 2170756 1167808 1160836
> Error displayed in diags.log:
> ===
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Failed to create new
> instance for plugin /opt/trafficserver/libexec/trafficserver/tslua.so (not a
> TS_SUCCESS return)
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Could not add rule at
> line #3; Aborting!
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: [ReverseProxy] Can't
> create new remap instance for plugin
> "/opt/trafficserver/libexec/trafficserver/tslua.so" - [ts_lua_add_module]
> luaL_loadfile /opt/trafficserver/etc/trafficserver/lua/process_remap.lua
> failed: not enough memory at line 3
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: something failed
> during BuildTable() -- check your remap plugins!
> [Mar 8 23:27:27.595] Server {0x2af92498b700} WARNING: failed to reload
> remap.config, not replacing!
> Lua VM memory size at that time ,ts.debug(FUNCTION..'Lua VM memory:
> '..collectgarbage("count"))
> [Mar 8 23:27:27.579] Server {0x2af92498b700} DIAG: (ts_lua) __init__(): Lua
> VM memory: 3629.7060546875
> This shows that Lua VMs are hitting the max capacity.
> Solution:
> ===
> I looked at the ts_lua code TSRemapDeleteInstance () [ts_lua.c ] and
> ts_lua_del_module() [ts_lua_util.c] which does cleaning of the lua memory for
> the instance. However the lua memory is not released and reused.
> So, I have added code to start the garbage collector in ts_lua_del_module() .
> int
> ts_lua_del_module(ts_lua_instance_conf *conf, ts_lua_main_ctx *arr, int n)
> {
> ….
> lua_newtable(L);
> lua_replace(L, LUA_GLOBALSINDEX); /* L[GLOBAL] = EMPTY */
> lua_gc(L, LUA_GCCOLLECT, 0);
> TSMutexUnlock(arr[i].mutexp);
> }
> return 0;
> }
> This has improved the situation. However, I also added garbage collection in
> ts_lua_add_module() at the end. With these two additions, we have tested the
> code, the memory utilization is stable and we could do config reload at lest
> 100 times with the background load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4266) ATS memory statistics shows that memory utilization is doubled after “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
[
https://issues.apache.org/jira/browse/TS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15207025#comment-15207025
]
Rajendra Kishore Bonumahanti commented on TS-4266:
--
I merged the pull request. Please confirm if it is successful.
> ATS memory statistics shows that memory utilization is doubled after
> “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
> --
>
> Key: TS-4266
> URL: https://issues.apache.org/jira/browse/TS-4266
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: sometime
>
>
> ATS memory statistics shows memory utilization is doubled after “traffic_ctl
> config reload”. We get “not enough memory” error in the subsequent attempt
> and “config reload” fails.
> ATS is configured with 100 map entries in remap.config, all share the same
> lua script.
> ATS is started: The memory information is..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1416092 670256 663736
> After 1st Config reload:
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1932660 1128084 1121544
> After 2nd config reload: It had failed with error “not enough memory” and
> memory status as..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 2170756 1167808 1160836
> Error displayed in diags.log:
> ===
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Failed to create new
> instance for plugin /opt/trafficserver/libexec/trafficserver/tslua.so (not a
> TS_SUCCESS return)
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Could not add rule at
> line #3; Aborting!
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: [ReverseProxy] Can't
> create new remap instance for plugin
> "/opt/trafficserver/libexec/trafficserver/tslua.so" - [ts_lua_add_module]
> luaL_loadfile /opt/trafficserver/etc/trafficserver/lua/process_remap.lua
> failed: not enough memory at line 3
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: something failed
> during BuildTable() -- check your remap plugins!
> [Mar 8 23:27:27.595] Server {0x2af92498b700} WARNING: failed to reload
> remap.config, not replacing!
> Lua VM memory size at that time ,ts.debug(FUNCTION..'Lua VM memory:
> '..collectgarbage("count"))
> [Mar 8 23:27:27.579] Server {0x2af92498b700} DIAG: (ts_lua) __init__(): Lua
> VM memory: 3629.7060546875
> This shows that Lua VMs are hitting the max capacity.
> Solution:
> ===
> I looked at the ts_lua code TSRemapDeleteInstance () [ts_lua.c ] and
> ts_lua_del_module() [ts_lua_util.c] which does cleaning of the lua memory for
> the instance. However the lua memory is not released and reused.
> So, I have added code to start the garbage collector in ts_lua_del_module() .
> int
> ts_lua_del_module(ts_lua_instance_conf *conf, ts_lua_main_ctx *arr, int n)
> {
> ….
> lua_newtable(L);
> lua_replace(L, LUA_GLOBALSINDEX); /* L[GLOBAL] = EMPTY */
> lua_gc(L, LUA_GCCOLLECT, 0);
> TSMutexUnlock(arr[i].mutexp);
> }
> return 0;
> }
> This has improved the situation. However, I also added garbage collection in
> ts_lua_add_module() at the end. With these two additions, we have tested the
> code, the memory utilization is stable and we could do config reload at lest
> 100 times with the background load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4266) ATS memory statistics shows that memory utilization is doubled after “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
[
https://issues.apache.org/jira/browse/TS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15195984#comment-15195984
]
Rajendra Kishore Bonumahanti commented on TS-4266:
--
Kit: I submitted pull request for the same. Please review and let me know your
comments.
https://github.com/brkishore/trafficserver/pull/1
> ATS memory statistics shows that memory utilization is doubled after
> “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
> --
>
> Key: TS-4266
> URL: https://issues.apache.org/jira/browse/TS-4266
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: sometime
>
>
> ATS memory statistics shows memory utilization is doubled after “traffic_ctl
> config reload”. We get “not enough memory” error in the subsequent attempt
> and “config reload” fails.
> ATS is configured with 100 map entries in remap.config, all share the same
> lua script.
> ATS is started: The memory information is..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1416092 670256 663736
> After 1st Config reload:
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1932660 1128084 1121544
> After 2nd config reload: It had failed with error “not enough memory” and
> memory status as..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 2170756 1167808 1160836
> Error displayed in diags.log:
> ===
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Failed to create new
> instance for plugin /opt/trafficserver/libexec/trafficserver/tslua.so (not a
> TS_SUCCESS return)
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Could not add rule at
> line #3; Aborting!
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: [ReverseProxy] Can't
> create new remap instance for plugin
> "/opt/trafficserver/libexec/trafficserver/tslua.so" - [ts_lua_add_module]
> luaL_loadfile /opt/trafficserver/etc/trafficserver/lua/process_remap.lua
> failed: not enough memory at line 3
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: something failed
> during BuildTable() -- check your remap plugins!
> [Mar 8 23:27:27.595] Server {0x2af92498b700} WARNING: failed to reload
> remap.config, not replacing!
> Lua VM memory size at that time ,ts.debug(FUNCTION..'Lua VM memory:
> '..collectgarbage("count"))
> [Mar 8 23:27:27.579] Server {0x2af92498b700} DIAG: (ts_lua) __init__(): Lua
> VM memory: 3629.7060546875
> This shows that Lua VMs are hitting the max capacity.
> Solution:
> ===
> I looked at the ts_lua code TSRemapDeleteInstance () [ts_lua.c ] and
> ts_lua_del_module() [ts_lua_util.c] which does cleaning of the lua memory for
> the instance. However the lua memory is not released and reused.
> So, I have added code to start the garbage collector in ts_lua_del_module() .
> int
> ts_lua_del_module(ts_lua_instance_conf *conf, ts_lua_main_ctx *arr, int n)
> {
> ….
> lua_newtable(L);
> lua_replace(L, LUA_GLOBALSINDEX); /* L[GLOBAL] = EMPTY */
> lua_gc(L, LUA_GCCOLLECT, 0);
> TSMutexUnlock(arr[i].mutexp);
> }
> return 0;
> }
> This has improved the situation. However, I also added garbage collection in
> ts_lua_add_module() at the end. With these two additions, we have tested the
> code, the memory utilization is stable and we could do config reload at lest
> 100 times with the background load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4266) ATS memory statistics shows that memory utilization is doubled after “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
[
https://issues.apache.org/jira/browse/TS-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187187#comment-15187187
]
Rajendra Kishore Bonumahanti commented on TS-4266:
--
Please assign the ticket to me. I can work on the solution if it is agreed.
> ATS memory statistics shows that memory utilization is doubled after
> “traffic_ctlconfig reload”. And it is failed as it cannot find enough memory.
> --
>
> Key: TS-4266
> URL: https://issues.apache.org/jira/browse/TS-4266
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Reporter: Rajendra Kishore Bonumahanti
>
> ATS memory statistics shows memory utilization is doubled after “traffic_ctl
> config reload”. We get “not enough memory” error in the subsequent attempt
> and “config reload” fails.
> ATS is configured with 100 map entries in remap.config, all share the same
> lua script.
> ATS is started: The memory information is..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1416092 670256 663736
> After 1st Config reload:
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 1932660 1128084 1121544
> After 2nd config reload: It had failed with error “not enough memory” and
> memory status as..
> [root@mtanjv8cdnc73 trafficserver]# pmap -x 113330 | grep total
> total kB 2170756 1167808 1160836
> Error displayed in diags.log:
> ===
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Failed to create new
> instance for plugin /opt/trafficserver/libexec/trafficserver/tslua.so (not a
> TS_SUCCESS return)
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: Could not add rule at
> line #3; Aborting!
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: [ReverseProxy] Can't
> create new remap instance for plugin
> "/opt/trafficserver/libexec/trafficserver/tslua.so" - [ts_lua_add_module]
> luaL_loadfile /opt/trafficserver/etc/trafficserver/lua/process_remap.lua
> failed: not enough memory at line 3
> [Mar 8 23:27:27.580] Server {0x2af92498b700} WARNING: something failed
> during BuildTable() -- check your remap plugins!
> [Mar 8 23:27:27.595] Server {0x2af92498b700} WARNING: failed to reload
> remap.config, not replacing!
> Lua VM memory size at that time ,ts.debug(FUNCTION..'Lua VM memory:
> '..collectgarbage("count"))
> [Mar 8 23:27:27.579] Server {0x2af92498b700} DIAG: (ts_lua) __init__(): Lua
> VM memory: 3629.7060546875
> This shows that Lua VMs are hitting the max capacity.
> Solution:
> ===
> I looked at the ts_lua code TSRemapDeleteInstance () [ts_lua.c ] and
> ts_lua_del_module() [ts_lua_util.c] which does cleaning of the lua memory for
> the instance. However the lua memory is not released and reused.
> So, I have added code to start the garbage collector in ts_lua_del_module() .
> int
> ts_lua_del_module(ts_lua_instance_conf *conf, ts_lua_main_ctx *arr, int n)
> {
> ….
> lua_newtable(L);
> lua_replace(L, LUA_GLOBALSINDEX); /* L[GLOBAL] = EMPTY */
> lua_gc(L, LUA_GCCOLLECT, 0);
> TSMutexUnlock(arr[i].mutexp);
> }
> return 0;
> }
> This has improved the situation. However, I also added garbage collection in
> ts_lua_add_module() at the end. With these two additions, we have tested the
> code, the memory utilization is stable and we could do config reload at lest
> 100 times with the background load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4163) ts_lua plugin document has incorrect 'context' information for the hook point constants
[ https://issues.apache.org/jira/browse/TS-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135135#comment-15135135 ] Rajendra Kishore Bonumahanti edited comment on TS-4163 at 2/5/16 10:18 PM: --- Kit, I tested TS_LUA_REQUEST_TRANSFORM hook with POST (chunked-encoded) request as suggested in Jira ticket TS-2825. This has executed the hook call back function successfully. And I have not observed any core dump. I have tried ~10 times. I did not observe the issue reported in the Jira ticket. This means that the table I have put in the document needs to be corrected/updated for TS_LUA_REQUEST_TRANSFORM. Please suggest me if I need to resubmit the pull request or you can update and merge. + | TS_HTTP_REQUEST_TRANSFORM_HOOK | TS_LUA_REQUEST_TRANSFORM | YES |YES | was (Author: rkishore): Kit, I tested TS_LUA_REQUEST_TRANSFORM hook with POST (chunked-encoded) request as suggested in Jira ticket TS-2825. This has executed the hook call back function successfully. And I have not observed any core dump. I have tried ~10 times. I did not observe the issue reported in the Jira ticket. This means that the table I have put in the document needs to be corrected/updated for TS_LUA_REQUEST_TRANSFORM. Please suggest me if I need to resubmit the pull request or you can update and merge. > ts_lua plugin document has incorrect 'context' information for the hook point > constants > --- > > Key: TS-4163 > URL: https://issues.apache.org/jira/browse/TS-4163 > Project: Traffic Server > Issue Type: Bug > Components: Docs >Reporter: Rajendra Kishore Bonumahanti >Priority: Minor > Fix For: Docs > > > The section "Hook point constants" in ts_lua Plugin document provides the > incorrect information on hook point constants being available to use > ts.hook() function. > Like TS_LUA_HOOK_PRE_REMAP or TS_LUA_HOOK_READ_REQUEST_HDR constants are not > useful to register the hook point in do_remap(). However, they can be used in > do_global_txn_start() or do_global_read_request() to register for the hook > call back functions. So, the 'context' information is irrelevant for this > section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4163) ts_lua plugin document has incorrect 'context' information for the hook point constants
[ https://issues.apache.org/jira/browse/TS-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135268#comment-15135268 ] Rajendra Kishore Bonumahanti commented on TS-4163: -- It is updated. Hope everything is fine. > ts_lua plugin document has incorrect 'context' information for the hook point > constants > --- > > Key: TS-4163 > URL: https://issues.apache.org/jira/browse/TS-4163 > Project: Traffic Server > Issue Type: Bug > Components: Docs >Reporter: Rajendra Kishore Bonumahanti >Priority: Minor > Fix For: Docs > > > The section "Hook point constants" in ts_lua Plugin document provides the > incorrect information on hook point constants being available to use > ts.hook() function. > Like TS_LUA_HOOK_PRE_REMAP or TS_LUA_HOOK_READ_REQUEST_HDR constants are not > useful to register the hook point in do_remap(). However, they can be used in > do_global_txn_start() or do_global_read_request() to register for the hook > call back functions. So, the 'context' information is irrelevant for this > section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4163) ts_lua plugin document has incorrect 'context' information for the hook point constants
[ https://issues.apache.org/jira/browse/TS-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126758#comment-15126758 ] Rajendra Kishore Bonumahanti commented on TS-4163: -- Yes. I will work on the fix. Could you please assign the ticket to me? > ts_lua plugin document has incorrect 'context' information for the hook point > constants > --- > > Key: TS-4163 > URL: https://issues.apache.org/jira/browse/TS-4163 > Project: Traffic Server > Issue Type: Bug > Components: Docs >Reporter: Rajendra Kishore Bonumahanti >Assignee: Kit Chan >Priority: Minor > Fix For: Docs > > > The section "Hook point constants" in ts_lua Plugin document provides the > incorrect information on hook point constants being available to use > ts.hook() function. > Like TS_LUA_HOOK_PRE_REMAP or TS_LUA_HOOK_READ_REQUEST_HDR constants are not > useful to register the hook point in do_remap(). However, they can be used in > do_global_txn_start() or do_global_read_request() to register for the hook > call back functions. So, the 'context' information is irrelevant for this > section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4163) ts_lua plugin document has incorrect 'context' information for the hook point constants
[ https://issues.apache.org/jira/browse/TS-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajendra Kishore Bonumahanti updated TS-4163: - Priority: Minor (was: Major) > ts_lua plugin document has incorrect 'context' information for the hook point > constants > --- > > Key: TS-4163 > URL: https://issues.apache.org/jira/browse/TS-4163 > Project: Traffic Server > Issue Type: Bug > Components: Docs >Reporter: Rajendra Kishore Bonumahanti >Priority: Minor > > The section "Hook point constants" in ts_lua Plugin document provides the > incorrect information on hook point constants being available to use > ts.hook() function. > Like TS_LUA_HOOK_PRE_REMAP or TS_LUA_HOOK_READ_REQUEST_HDR constants are not > useful to register the hook point in do_remap(). However, they can be used in > do_global_txn_start() or do_global_read_request() to register for the hook > call back functions. So, the 'context' information is irrelevant for this > section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4163) ts_lua plugin document has incorrect 'context' information for the hook point constants
[ https://issues.apache.org/jira/browse/TS-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajendra Kishore Bonumahanti updated TS-4163: - I am working on the document change. 'Shu Kit Chan' is consulted on this issue. He suggested to remove context information for this. > ts_lua plugin document has incorrect 'context' information for the hook point > constants > --- > > Key: TS-4163 > URL: https://issues.apache.org/jira/browse/TS-4163 > Project: Traffic Server > Issue Type: Bug > Components: Docs >Reporter: Rajendra Kishore Bonumahanti >Priority: Minor > > The section "Hook point constants" in ts_lua Plugin document provides the > incorrect information on hook point constants being available to use > ts.hook() function. > Like TS_LUA_HOOK_PRE_REMAP or TS_LUA_HOOK_READ_REQUEST_HDR constants are not > useful to register the hook point in do_remap(). However, they can be used in > do_global_txn_start() or do_global_read_request() to register for the hook > call back functions. So, the 'context' information is irrelevant for this > section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4163) ts_lua plugin document has incorrect 'context' information for the hook point constants
Rajendra Kishore Bonumahanti created TS-4163: Summary: ts_lua plugin document has incorrect 'context' information for the hook point constants Key: TS-4163 URL: https://issues.apache.org/jira/browse/TS-4163 Project: Traffic Server Issue Type: Bug Components: Docs Reporter: Rajendra Kishore Bonumahanti The section "Hook point constants" in ts_lua Plugin document provides the incorrect information on hook point constants being available to use ts.hook() function. Like TS_LUA_HOOK_PRE_REMAP or TS_LUA_HOOK_READ_REQUEST_HDR constants are not useful to register the hook point in do_remap(). However, they can be used in do_global_txn_start() or do_global_read_request() to register for the hook call back functions. So, the 'context' information is irrelevant for this section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
