[jira] [Created] (TS-3545) Make traffic_line and traffic_ctl more verbose
David Carlin created TS-3545: Summary: Make traffic_line and traffic_ctl more verbose Key: TS-3545 URL: https://issues.apache.org/jira/browse/TS-3545 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: David Carlin Couple suggestions: Can 'traffic_line -s' and 'traffic_ctl config set' send a warning after making a setting change that it will take 5-10 seconds to take effect? Currently the command will warn you when a reboot is needed, but it would be handy if it by default reported when a reboot is unnecessary as well. Neither tool outputs anything usually when making a setting change, leaving the user to wonder if it worked or not.. I only recently found out there was a delay in making a change and having it take effect; I frequently just thought traffic_line -s didn't work for a particular setting, but I may not have been waiting long enough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3533:
Backport to Version: (was: 5.3.0)
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3546) Remove TSPluginRegister API or make the version checking work
Bryan Call created TS-3546:
--
Summary: Remove TSPluginRegister API or make the version checking
work
Key: TS-3546
URL: https://issues.apache.org/jira/browse/TS-3546
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Bryan Call
IRC discussion about it:
{code}
09:29:39] @bcall why do we want plugins to register?
[09:30:06] @jpeach afaik historically it's always been a requirement
[09:30:30] @bcallI don't think so
[09:30:33] @jpeach imho there should be a way for plugin to fail at
startup
[09:30:53] @jpeach if register does nothing useful then we should just
remove it
[09:31:46] @bcallit was used for API version checking from what I
remember
[09:31:52] @jpeach but registration creates internal info that could be
used for something interesting
[09:31:54] @bcalland I never did it in my plugins
[09:32:18] @sudheerv fwiw, i think i didn't either ;)
[09:32:52] @jpeach heh
[09:32:54] @bcallit is helpful for 3rd party plugins - vender, email, etc
[09:33:13] @bcalland api version checking
[09:33:14] @jpeach that information never goes anywhere
[09:33:20] @bcallI can see the merit of the version checking
[09:33:21] @jpeach the version checking does nothing
[09:33:28] @bcalleven better :)
[09:33:40] @jpeach sounds like you should nuke it for 6.0
[09:34:09] @bcallI will file a bug
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3546) Remove TSPluginRegister API or make the version checking work
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507399#comment-14507399
]
James Peach commented on TS-3546:
-
My understanding is that registration was always required. I don't think that
optional registration makes sense; it should be compulsory or not at all.
I think that there are benefits to knowing what plugins are loaded in the core
that we don't take advantage of. If we ever implement plugin reloading, then
the registered plugin instance is the natural place to track the resources
allocated by a plugin. There is a need to track what a plugin does, for example
TSHttpConnectWithPluginId(), which could have been implemented to automatically
chain back to the plugin registration if we associated continuations with
plugins (which we could do relatively easily).
Remove TSPluginRegister API or make the version checking work
-
Key: TS-3546
URL: https://issues.apache.org/jira/browse/TS-3546
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Affects Versions: 5.3.0
Reporter: Bryan Call
Fix For: 6.0.0
IRC discussion about it:
{code}
09:29:39] @bcall why do we want plugins to register?
[09:30:06] @jpeach afaik historically it's always been a requirement
[09:30:30] @bcall I don't think so
[09:30:33] @jpeach imho there should be a way for plugin to fail at
startup
[09:30:53] @jpeach if register does nothing useful then we should just
remove it
[09:31:46] @bcall it was used for API version checking from what I
remember
[09:31:52] @jpeach but registration creates internal info that could be
used for something interesting
[09:31:54] @bcall and I never did it in my plugins
[09:32:18] @sudheerv fwiw, i think i didn't either ;)
[09:32:52] @jpeach heh
[09:32:54] @bcall it is helpful for 3rd party plugins - vender, email, etc
[09:33:13] @bcall and api version checking
[09:33:14] @jpeach that information never goes anywhere
[09:33:20] @bcall I can see the merit of the version checking
[09:33:21] @jpeach the version checking does nothing
[09:33:28] @bcall even better :)
[09:33:40] @jpeach sounds like you should nuke it for 6.0
[09:34:09] @bcall I will file a bug
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3533:
Fix Version/s: (was: 6.0.0)
5.3.0
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3533:
Fix Version/s: 6.0.0
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3546) Remove TSPluginRegister API or make the version checking work
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3546:
---
Fix Version/s: 6.0.0
Remove TSPluginRegister API or make the version checking work
-
Key: TS-3546
URL: https://issues.apache.org/jira/browse/TS-3546
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Affects Versions: 5.3.0
Reporter: Bryan Call
Fix For: 6.0.0
IRC discussion about it:
{code}
09:29:39] @bcall why do we want plugins to register?
[09:30:06] @jpeach afaik historically it's always been a requirement
[09:30:30] @bcall I don't think so
[09:30:33] @jpeach imho there should be a way for plugin to fail at
startup
[09:30:53] @jpeach if register does nothing useful then we should just
remove it
[09:31:46] @bcall it was used for API version checking from what I
remember
[09:31:52] @jpeach but registration creates internal info that could be
used for something interesting
[09:31:54] @bcall and I never did it in my plugins
[09:32:18] @sudheerv fwiw, i think i didn't either ;)
[09:32:52] @jpeach heh
[09:32:54] @bcall it is helpful for 3rd party plugins - vender, email, etc
[09:33:13] @bcall and api version checking
[09:33:14] @jpeach that information never goes anywhere
[09:33:20] @bcall I can see the merit of the version checking
[09:33:21] @jpeach the version checking does nothing
[09:33:28] @bcall even better :)
[09:33:40] @jpeach sounds like you should nuke it for 6.0
[09:34:09] @bcall I will file a bug
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3546) Remove TSPluginRegister API or make the version checking work
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3546:
---
Issue Type: Improvement (was: Bug)
Remove TSPluginRegister API or make the version checking work
-
Key: TS-3546
URL: https://issues.apache.org/jira/browse/TS-3546
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Affects Versions: 5.3.0
Reporter: Bryan Call
Fix For: 6.0.0
IRC discussion about it:
{code}
09:29:39] @bcall why do we want plugins to register?
[09:30:06] @jpeach afaik historically it's always been a requirement
[09:30:30] @bcall I don't think so
[09:30:33] @jpeach imho there should be a way for plugin to fail at
startup
[09:30:53] @jpeach if register does nothing useful then we should just
remove it
[09:31:46] @bcall it was used for API version checking from what I
remember
[09:31:52] @jpeach but registration creates internal info that could be
used for something interesting
[09:31:54] @bcall and I never did it in my plugins
[09:32:18] @sudheerv fwiw, i think i didn't either ;)
[09:32:52] @jpeach heh
[09:32:54] @bcall it is helpful for 3rd party plugins - vender, email, etc
[09:33:13] @bcall and api version checking
[09:33:14] @jpeach that information never goes anywhere
[09:33:20] @bcall I can see the merit of the version checking
[09:33:21] @jpeach the version checking does nothing
[09:33:28] @bcall even better :)
[09:33:40] @jpeach sounds like you should nuke it for 6.0
[09:34:09] @bcall I will file a bug
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3546) Remove TSPluginRegister API or make the version checking work
[
https://issues.apache.org/jira/browse/TS-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3546:
---
Affects Version/s: 5.3.0
Remove TSPluginRegister API or make the version checking work
-
Key: TS-3546
URL: https://issues.apache.org/jira/browse/TS-3546
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 5.3.0
Reporter: Bryan Call
Fix For: 6.0.0
IRC discussion about it:
{code}
09:29:39] @bcall why do we want plugins to register?
[09:30:06] @jpeach afaik historically it's always been a requirement
[09:30:30] @bcall I don't think so
[09:30:33] @jpeach imho there should be a way for plugin to fail at
startup
[09:30:53] @jpeach if register does nothing useful then we should just
remove it
[09:31:46] @bcall it was used for API version checking from what I
remember
[09:31:52] @jpeach but registration creates internal info that could be
used for something interesting
[09:31:54] @bcall and I never did it in my plugins
[09:32:18] @sudheerv fwiw, i think i didn't either ;)
[09:32:52] @jpeach heh
[09:32:54] @bcall it is helpful for 3rd party plugins - vender, email, etc
[09:33:13] @bcall and api version checking
[09:33:14] @jpeach that information never goes anywhere
[09:33:20] @bcall I can see the merit of the version checking
[09:33:21] @jpeach the version checking does nothing
[09:33:28] @bcall even better :)
[09:33:40] @jpeach sounds like you should nuke it for 6.0
[09:34:09] @bcall I will file a bug
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3545) Make traffic_line and traffic_ctl more verbose
[ https://issues.apache.org/jira/browse/TS-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507387#comment-14507387 ] James Peach commented on TS-3545: - There is no output for setting configuration that is marked as dynamic because it's not really possible to know precisely what to emit here. The implication is that the setting is applied immediately, but you can't tell when the actual subsystem change is triggered (if at all). Maybe we could fix this in docs. Make traffic_line and traffic_ctl more verbose -- Key: TS-3545 URL: https://issues.apache.org/jira/browse/TS-3545 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: David Carlin Couple suggestions: Can 'traffic_line -s' and 'traffic_ctl config set' send a warning after making a setting change that it will take 5-10 seconds to take effect? Currently the command will warn you when a reboot is needed, but it would be handy if it by default reported when a reboot is unnecessary as well. Neither tool outputs anything usually when making a setting change, leaving the user to wonder if it worked or not.. I only recently found out there was a delay in making a change and having it take effect; I frequently just thought traffic_line -s didn't work for a particular setting, but I may not have been waiting long enough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507406#comment-14507406
]
ASF subversion and git services commented on TS-3533:
-
Commit 33cc7b32e23f72db56ff2fa10a8d5c1ee54fe2cf in trafficserver's branch
refs/heads/5.3.x from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=33cc7b3 ]
TS-3533: Update CHANGES
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507402#comment-14507402
]
ASF subversion and git services commented on TS-3533:
-
Commit 37b2819b746599e591ca15600488356fe546aea9 in trafficserver's branch
refs/heads/5.3.x from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=37b2819 ]
TS-3533: Revert [TS-3294]: Fix global plugin's dlhandle resource leak
This reverts commit ad9958b9240f784ce5cf0045fd975d143df2ea0e.
Conflicts:
proxy/Plugin.cc
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3529) Add a config option to allow ATS to start even if some certificates are bad
[ https://issues.apache.org/jira/browse/TS-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507401#comment-14507401 ] ASF subversion and git services commented on TS-3529: - Commit bf4ba0cf2741d7d189deba608154b07aa61dce46 in trafficserver's branch refs/heads/5.3.x from shinrich [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bf4ba0c ] TS-3529: Add a config to allow ATS to start up even if some certificates are bad. (cherry picked from commit ef36a509c0a3cf0309ad563e980d7e002f9b2d9c) Conflicts: CHANGES Add a config option to allow ATS to start even if some certificates are bad --- Key: TS-3529 URL: https://issues.apache.org/jira/browse/TS-3529 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Priority: Blocker Fix For: 5.3.0, 6.0.0 In fixing TS-3329, we changed the ATS start up behavior to fail to start if any of the entries of ssl_multicert.config fails to load. This changes the functionality of ATS in from 5.2 to 5.3. For many/most use cases, this is a desirable change. However, for some use cases, you want to serve and start up even if some of the entries fail to load. We will add a records config entry proxy.config.ssl.server.multicert.exit_on_load_fail It will default to 1 on 5.x. May want to change the default to 0 when we move to 6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507261#comment-14507261
]
Sudheer Vinukonda commented on TS-3533:
---
Thanks to [~rokubo] (I now actually recall that even [~kichan] once mentioned
the issue in passing..) for pointing that this problem occurs with plugins that
do not call *TSPluginRegister*.
Digging further, it seems that the problem was introduced with TS-3337 (commit
SHA 7f0f3a47b253d361a16c33413b4501a5ff5d69fe). We should probably revert this
seemingly incompatible change for 5.3 and revisit this for 6.0.
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507311#comment-14507311 ] ASF GitHub Bot commented on TS-2650: GitHub user ffcai opened a pull request: https://github.com/apache/trafficserver/pull/188 TS-2650 add a trailing zero char When concatenate `port` after `host:` using `ink_strlcpy()`, a trailing zero char is needed. Happen to find this when I test redirection use case. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ffcai/trafficserver TS-2650-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/188.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #188 commit fedcb82c0f7b510050f12c6df77828a43baf9817 Author: Feifei Cai ff...@yahoo-inc.com Date: 2015-04-22T15:46:42Z add a trailing zero char Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507289#comment-14507289
]
Kit Chan commented on TS-3533:
--
just fyi, i was briefly tracing this before the summit and i think the problem
is happening after this checkin -
https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=ad9958b9240f784ce5cf0045fd975d143df2ea0e
but i admit that i did not pursue this further after doing proper
TSPluginRegister() on my plugins and it then worked
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507297#comment-14507297
]
Sudheer Vinukonda commented on TS-3533:
---
Yeah, the issue was exposed with the commit
ad9958b9240f784ce5cf0045fd975d143df2ea0e, but, it was actually introduced in
TS-3337. In fact, without the commit ad9958b9240f784ce5cf0045fd975d143df2ea0e,
it would have been far worse, since the plugin would simply not load at all
without issuing any warnings/errors and letting traffic_server come up.
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3541) Eliminate interim cache
[ https://issues.apache.org/jira/browse/TS-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-3541: Summary: Eliminate interim cache (was: Eliminate interrim cache) Eliminate interim cache --- Key: TS-3541 URL: https://issues.apache.org/jira/browse/TS-3541 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: compatibility Fix For: 6.0.0 This feature is poorly supported, and causes grief for cache development due to how it #ifdef’s with the system. There are plans for a new system that would make the concept of cache hierarchies generic. In the mean time, the suggestion is that if you need this, you use one of 1) Assigning content to volumes and disks via our existing configs. 2) Use Linux’s bcache feature, which comes with Linux 3.10 or later. I suspect e.g. ZFS has something similar. 3) Use a third party system to implement the hybrid device (e.g. flash cache or EnhanceIO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3511) Perl API seems to have a permission issue
[
https://issues.apache.org/jira/browse/TS-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507410#comment-14507410
]
James Peach commented on TS-3511:
-
Consider adding a compatibility symlink to the old socket name?
Perl API seems to have a permission issue
-
Key: TS-3511
URL: https://issues.apache.org/jira/browse/TS-3511
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Mark Torluemke
Priority: Blocker
Fix For: 6.0.0
Problems with the perl an grabbing stats:
{code}
[bcall@l1]$ sudo /xxx/ats_gather # also tried -u nobody
Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
[bcall@l1]$ sudo traffic_line -m . | grep restrict
proxy.config.admin.api.restricted 0 # tried with 0|1
line 77:
my $cli = new Apache::TS::AdminClient(socket_path =
$xxx/trafficserver/mgmtapisocket);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3511) Perl API seems to have a permission issue
[
https://issues.apache.org/jira/browse/TS-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507469#comment-14507469
]
Bryan Call commented on TS-3511:
Yeah, I did, but there is a fallback, so that is good. Once 6.0.0 comes out we
will just change the name in our perl script to the correct one.
Perl API seems to have a permission issue
-
Key: TS-3511
URL: https://issues.apache.org/jira/browse/TS-3511
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Mark Torluemke
Priority: Blocker
Fix For: 6.0.0
Problems with the perl an grabbing stats:
{code}
[bcall@l1]$ sudo /xxx/ats_gather # also tried -u nobody
Error opening socket - connect: Connection refused at /xxx/ats_gather line 77
[bcall@l1]$ sudo traffic_line -m . | grep restrict
proxy.config.admin.api.restricted 0 # tried with 0|1
line 77:
my $cli = new Apache::TS::AdminClient(socket_path =
$xxx/trafficserver/mgmtapisocket);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507404#comment-14507404
]
ASF subversion and git services commented on TS-3533:
-
Commit a54e87617dce540e0499b2a9d9870dce7ce016ce in trafficserver's branch
refs/heads/5.3.x from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a54e876 ]
TS-3533: Revert TS-3337: remove internal plugin SDK enumeration
This reverts commit 7f0f3a47b253d361a16c33413b4501a5ff5d69fe.
Conflicts:
CHANGES
proxy/InkAPI.cc
proxy/Plugin.cc
proxy/Plugin.h
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3294) 5.3.0 Coverity fixes for Sudheer
[ https://issues.apache.org/jira/browse/TS-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507403#comment-14507403 ] ASF subversion and git services commented on TS-3294: - Commit 37b2819b746599e591ca15600488356fe546aea9 in trafficserver's branch refs/heads/5.3.x from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=37b2819 ] TS-3533: Revert [TS-3294]: Fix global plugin's dlhandle resource leak This reverts commit ad9958b9240f784ce5cf0045fd975d143df2ea0e. Conflicts: proxy/Plugin.cc 5.3.0 Coverity fixes for Sudheer Key: TS-3294 URL: https://issues.apache.org/jira/browse/TS-3294 Project: Traffic Server Issue Type: Improvement Components: Cleanup, Quality Reporter: Sudheer Vinukonda Assignee: Sudheer Vinukonda Fix For: 5.3.0 Tracker Jira for 5.3.0 Coverity Fixes (Sudheer Vinukonda) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507539#comment-14507539 ] ASF GitHub Bot commented on TS-2650: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/188 Redirect handling enhancements in ATS - Key: TS-2650 URL: https://issues.apache.org/jira/browse/TS-2650 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Assignee: Bryan Call Labels: review, yahoo Fix For: 5.0.0 Attachments: ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff, ts2650.diff This Jira attempts to enhance/fix multiple issues found with ATS's support for redirect follow. Below is a summary of issues: 1. Support relative path in the location header in the 301/302/303 response. Description: Currently, if ATS receives a relative url path (with either the host or the scheme missing) in the location header in the 302 redirect request, it returns a 400 Host Header Required error. This enhancement is to try the redirection with the current origin connection's host/scheme when that happens. 2. Strip off default ports from Host header during redirect follow. Description: ATS includes port in the host header as host:port during redirect follow. It has been observed that some origins choke (and return 4xx error) when the default port (80/http, 443/https) is included within the host header. This enhancement is to strip off the default port (80/http, 443/https) from the host header during redirect follow. This behavior is controlled via a configuration parameter proxy.config.http.redirect_host_no_port. When enabled, ATS will strip off the default port from the host header during redirect follow. Note that the default setting for proxy.config.http.redirect_host_no_port is disabled, which means, ATS will continue to include the port in the host header. 3. Force DNS lookup during redirect follow Description: It has been observed that, ATS doesn't perform a DNS lookup during redirect follow. This may work when the host is unchanged during redirect follow, but, will fail if the host is changed. This fix forces dns lookup (either by way of hostdb lookup or an altogether new dns lookup) during redirect follow 4. Handle null path correctly during redirect follow Description: It has been observed that, if a subsequent redirect follow includes null path (e.g. /), ATS incorrectly uses the path received during a previous redirect request. This fix resets the path during each redirect to ensure that the path is correctly set to the newly received value. 5. Cache not working during redirect Description: It has been observed that ATS is not writing to cache the final response at the end of a successful 3xx redirect follow. This fix is to force ATS write to cache a valid non-3xx response received at the end of a redirect follow. 6. Support 303 status code to trigger redirect follow Description: Currently, ATS supports only 301/302 based redirect follow. This enhancement is to also handle 303 based redirect follow. Note that, in terms of the response and redirect follow handling, 303 handling is identical to 301/302, except for the status code. 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has a bug that breaks redirect handling. This fix is to allow redirect handling to be completed (unto the configured max number of attempts) before invoking the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3337) Remove internal plugin SDK versioning
[ https://issues.apache.org/jira/browse/TS-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507405#comment-14507405 ] ASF subversion and git services commented on TS-3337: - Commit a54e87617dce540e0499b2a9d9870dce7ce016ce in trafficserver's branch refs/heads/5.3.x from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a54e876 ] TS-3533: Revert TS-3337: remove internal plugin SDK enumeration This reverts commit 7f0f3a47b253d361a16c33413b4501a5ff5d69fe. Conflicts: CHANGES proxy/InkAPI.cc proxy/Plugin.cc proxy/Plugin.h Remove internal plugin SDK versioning - Key: TS-3337 URL: https://issues.apache.org/jira/browse/TS-3337 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: James Peach Assignee: James Peach Fix For: 5.3.0 Remove the internal plugin SDK version enumeration, which just tracks the API version. Stop loading plugins that don't match the supported API version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3533:
---
Assignee: Phil Sorber (was: Bryan Call)
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Phil Sorber
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-3533.
--
Resolution: Fixed
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Phil Sorber
Fix For: 5.3.0, 6.0.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3533) Coring when a plugin is enabled with 5.3.0
[
https://issues.apache.org/jira/browse/TS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3533:
Fix Version/s: (was: 6.0.0)
Coring when a plugin is enabled with 5.3.0
--
Key: TS-3533
URL: https://issues.apache.org/jira/browse/TS-3533
Project: Traffic Server
Issue Type: Bug
Components: Core, Plugins
Affects Versions: 5.3.0
Reporter: Bryan Call
Assignee: Phil Sorber
Fix For: 5.3.0
Seeing this core in 5.3.0 when enabling quick_filter (our plugin):
{code}
(gdb) bt full
#0 0x7fffed265a72 in ?? ()
No symbol table info available.
#1 0x00521b88 in INKContInternal::handle_event (this=0x18a0240,
event=60017, edata=0x7fff04e49980) at InkAPI.cc:1003
No locals.
#2 0x0050dbe0 in Continuation::handleEvent (this=0x18a0240,
event=60017, data=0x7fff04e49980) at
../iocore/eventsystem/I_Continuation.h:145
No locals.
#3 0x005223cf in APIHook::invoke (this=0x18a12e0, event=60017,
edata=0x7fff04e49980) at InkAPI.cc:1221
No locals.
#4 0x005e5eb3 in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1381
plugin_lock = false
plugin_mutex = {m_ptr = 0x0}
hook = 0x18a12e0
api_next = HttpSM::API_RETURN_UNKNOWN
__func__ = state_api_callout
#5 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#6 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#7 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#8 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#9 0x005f8900 in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6890
__func__ = set_next_state
#10 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#11 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#12 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
#13 0x005f1e7f in HttpSM::do_api_callout_internal
(this=0x7fff04e49980) at HttpSM.cc:4863
No locals.
#14 0x005feec7 in HttpSM::do_api_callout (this=0x7fff04e49980) at
HttpSM.cc:442
No locals.
#15 0x005f87bc in HttpSM::set_next_state (this=0x7fff04e49980) at
HttpSM.cc:6876
__func__ = set_next_state
#16 0x005f8756 in HttpSM::call_transact_and_set_next_state
(this=0x7fff04e49980, f=0) at HttpSM.cc:6843
__func__ = call_transact_and_set_next_state
#17 0x005e62ae in HttpSM::handle_api_return (this=0x7fff04e49980) at
HttpSM.cc:1517
No locals.
#18 0x005e614a in HttpSM::state_api_callout (this=0x7fff04e49980,
event=0, data=0x0) at HttpSM.cc:1455
api_next = HttpSM::API_RETURN_CONTINUE
__func__ = state_api_callout
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3547) SSLNetVConnection: switch to a vectored write
[
https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508207#comment-14508207
]
Brian Geffon commented on TS-3547:
--
UnixNetVConnection uses {{writev}} but OpenSSL only has SSL_write it doesn't
have an SSL_writev.
SSLNetVConnection: switch to a vectored write
-
Key: TS-3547
URL: https://issues.apache.org/jira/browse/TS-3547
Project: Traffic Server
Issue Type: Bug
Reporter: Thomas Jackson
UnixNetVConnection does a vectored write which bunches blocks together until
the outgoing buffer will fill up. This means we can better fill the packets,
and should give us a bit of a performance boost to SSL writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3549) configurable option to avoid thundering herd due to concurrent requests for the same object
Sudheer Vinukonda created TS-3549:
-
Summary: configurable option to avoid thundering herd due to
concurrent requests for the same object
Key: TS-3549
URL: https://issues.apache.org/jira/browse/TS-3549
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Sudheer Vinukonda
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g manifest
files) or a complete cache miss (e.g segment files). ATS currently supports
different types of connection collapse (e.g. *read-while-write* functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*)
but, in order for this to kick-in, ATS requires the complete response headers
for the object be received and validated. In other words, until this happens,
any number of incoming requests for the same object that result in a cache miss
or a cache stale would be forwarded to the origin. For a scenario such as a
live event, this leaves a sufficiently significant window, where there could be
100's of requests being forwarded to the origin for the same object. It has
been observed during production that this results in significant increase in
latency for the objects waiting in read-while-write state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get the
read lock for the object as configured. With these configured, ATS would retry
to get the read lock for as long and if it's still not available due to the
write lock being held by the first request that was forwarded to the origin
(for e.g. the response headers have not been received yet), then all the
waiting requests would simply be forwarded to the origin (by disabling cache
for each of them).
It is almost impossible to get the above settings accurate to help in all
possible situations (traffic, concurrent connections, network conditions etc).
Due to this reason, a configurable workaround is proposed below that avoids the
thundering herd completely.
Basically, when configured, on failing to obtain a write lock for an object
(which means, there's another ongoing parallel request for the same object that
was forwarded to the origin), if it's a cache refresh miss, a stale copy of the
object is served, while if it's a complete cache miss, a *502* error is
returned to let the client (e.g. player) to reattempt. The *502* error also
includes a special internal ATS header named {{@ats-internal-messages}} with
the appropriate value to allow for custom logging or for plugins to take any
appropriate actions (e.g. prevent a fail-over if there's such a plugin that
does fail-over on a regular 502 error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3549) configurable option to avoid thundering herd due to concurrent requests for the same object
[
https://issues.apache.org/jira/browse/TS-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3549:
--
Affects Version/s: 5.3.0
Fix Version/s: 6.0.0
Assignee: Sudheer Vinukonda
configurable option to avoid thundering herd due to concurrent requests for
the same object
---
Key: TS-3549
URL: https://issues.apache.org/jira/browse/TS-3549
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Affects Versions: 5.3.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 6.0.0
Attachments: TS-3549.diff
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g
manifest files) or a complete cache miss (e.g segment files). ATS currently
supports different types of connection collapse (e.g. *read-while-write*
functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*)
but, in order for this to kick-in, ATS requires the complete response
headers for the object be received and validated. In other words, until this
happens, any number of incoming requests for the same object that result in a
cache miss or a cache stale would be forwarded to the origin. For a scenario
such as a live event, this leaves a sufficiently significant window, where
there could be 100's of requests being forwarded to the origin for the same
object. It has been observed during production that this results in
significant increase in latency for the objects waiting in read-while-write
state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get
the read lock for the object as configured. With these configured, ATS would
retry to get the read lock for as long and if it's still not available due to
the write lock being held by the first request that was forwarded to the
origin (for e.g. the response headers have not been received yet), then all
the waiting requests would simply be forwarded to the origin (by disabling
cache for each of them).
It is almost impossible to get the above settings accurate to help in all
possible situations (traffic, concurrent connections, network conditions
etc). Due to this reason, a configurable workaround is proposed below that
avoids the thundering herd completely.
Basically, when configured, on failing to obtain a write lock for an object
(which means, there's another ongoing parallel request for the same object
that was forwarded to the origin), if it's a cache refresh miss, a stale copy
of the object is served, while if it's a complete cache miss, a *502* error
is returned to let the client (e.g. player) to reattempt. The *502* error
also includes a special internal ATS header named {{@ats-internal-messages}}
with the appropriate value to allow for custom logging or for plugins to take
any appropriate actions (e.g. prevent a fail-over if there's such a plugin
that does fail-over on a regular 502 error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3549) configurable option to avoid thundering herd due to concurrent requests for the same object
[
https://issues.apache.org/jira/browse/TS-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3549:
--
Attachment: TS-3549.diff
configurable option to avoid thundering herd due to concurrent requests for
the same object
---
Key: TS-3549
URL: https://issues.apache.org/jira/browse/TS-3549
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Affects Versions: 5.3.0
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 6.0.0
Attachments: TS-3549.diff
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g
manifest files) or a complete cache miss (e.g segment files). ATS currently
supports different types of connection collapse (e.g. *read-while-write*
functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*)
but, in order for this to kick-in, ATS requires the complete response
headers for the object be received and validated. In other words, until this
happens, any number of incoming requests for the same object that result in a
cache miss or a cache stale would be forwarded to the origin. For a scenario
such as a live event, this leaves a sufficiently significant window, where
there could be 100's of requests being forwarded to the origin for the same
object. It has been observed during production that this results in
significant increase in latency for the objects waiting in read-while-write
state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get
the read lock for the object as configured. With these configured, ATS would
retry to get the read lock for as long and if it's still not available due to
the write lock being held by the first request that was forwarded to the
origin (for e.g. the response headers have not been received yet), then all
the waiting requests would simply be forwarded to the origin (by disabling
cache for each of them).
It is almost impossible to get the above settings accurate to help in all
possible situations (traffic, concurrent connections, network conditions
etc). Due to this reason, a configurable workaround is proposed below that
avoids the thundering herd completely.
Basically, when configured, on failing to obtain a write lock for an object
(which means, there's another ongoing parallel request for the same object
that was forwarded to the origin), if it's a cache refresh miss, a stale copy
of the object is served, while if it's a complete cache miss, a *502* error
is returned to let the client (e.g. player) to reattempt. The *502* error
also includes a special internal ATS header named {{@ats-internal-messages}}
with the appropriate value to allow for custom logging or for plugins to take
any appropriate actions (e.g. prevent a fail-over if there's such a plugin
that does fail-over on a regular 502 error).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3547) SSLNetVConnection: switch to a vectored write
[
https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508337#comment-14508337
]
Brian Geffon commented on TS-3547:
--
[~shinrich] do you have any thoughts why two calls to {{SSL_write}} that are
basically back-to-back would result in such a large delay between data going
over the wire?
SSLNetVConnection: switch to a vectored write
-
Key: TS-3547
URL: https://issues.apache.org/jira/browse/TS-3547
Project: Traffic Server
Issue Type: Bug
Reporter: Thomas Jackson
UnixNetVConnection does a vectored write which bunches blocks together until
the outgoing buffer will fill up. This means we can better fill the packets,
and should give us a bit of a performance boost to SSL writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] daemon updated TS-3550: --- Affects Version/s: 5.2.1 Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3550) Segmentation fault (Address not mapped to object
daemon created TS-3550: -- Summary: Segmentation fault (Address not mapped to object Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: daemon traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2920) Stale_While_revalidate
[ https://issues.apache.org/jira/browse/TS-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508321#comment-14508321 ] Sudheer Vinukonda commented on TS-2920: --- Fyi - refer TS-3549 which sort of does the connection collapse along with the SWR requirement by returning a stale copy based on a configurable option. I plan to push the changes pretty soon based on the feedback. Stale_While_revalidate -- Key: TS-2920 URL: https://issues.apache.org/jira/browse/TS-2920 Project: Traffic Server Issue Type: Bug Components: Performance, Plugins Reporter: Faysal Banna Assignee: Alan M. Carroll Labels: crash Fix For: 6.0.0 trafficserver 5.0.0 release version FATAL: InkAPI.cc:2670: failed assert `sdk_sanity_check_mbuffer(bufp) == TS_SUCCESS` /usr/local/bin/traffic_server - STACK TRACE: /usr/local/lib/libtsutil.so.5(+0x1e3a7)[0x2b6db45e93a7] /usr/local/lib/libtsutil.so.5(+0x1e3a7)[0x2b6db45e93a7] /usr/local/lib/libtsutil.so.5(+0x1d45f)[0x2b6db45e845f] /usr/local/lib/libtsutil.so.5(+0x1d45f)[0x2b6db45e845f] /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ba43f] /usr/local/libexec/trafficserver/stale_while_revalidate.so(+0x308a)[0x2b6dbb98308a] /usr/local/bin/traffic_server(EThread::process_event(Event*, int)+0x170)[0x737210] /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ba43f] /usr/local/bin/traffic_server(EThread::execute()+0x793)[0x737de3] /usr/local/libexec/trafficserver/stale_while_revalidate.so(+0x308a)[0x2b6dbb98308a] /usr/local/bin/traffic_server[0x736b5a] /usr/local/bin/traffic_server(EThread::process_event(Event*, int)+0x170)[0x737210] /lib64/libpthread.so.0(+0x7f33)[0x2b6db60a2f33] /usr/local/bin/traffic_server(EThread::execute()+0x793)[0x737de3] /lib64/libc.so.6(clone+0x6d)[0x2b6db713eded] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3547) SSLNetVConnection: switch to a vectored write
[
https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508309#comment-14508309
]
Brian Geffon edited comment on TS-3547 at 4/23/15 2:09 AM:
---
After investigation with [~jacksontj] it appears that
{{SSLNetVConnection::load_buffer_and_write}} is called with all of the data in
multiple IOBufferBlock so it results in multiple calls to {{SSLWriteBuffer}}.
To experiment we created a small patch that just copies all of the
IOBufferBlocks to a single block of memory followed by a single
{{SSLWriteBuffer}} call and it resolves the problem. So since this is obviously
not a viable solution we need to figure out why the {{SSL_write}} calls are
being split up in such a strange way.
We had a second theory that was related to the BIO flush calls, so we made a
patch that would only call BIO flush once all the {{SSL_writes}} are complete
and that did not seem to resolve the problem.
We should be able to call SSL_write multiple times without having it delay the
write to socket for such a large amount of time.
was (Author: briang):
After investigation with [~jacksontj] it appears that
{{SSLNetVConnection::load_buffer_and_write}} is called with all of the data in
multiple IOBufferBlock so it results in multiple calls to {{SSLWriteBuffer}}.
To experiment we created a small patch that just copies all of the
IOBufferBlocks to a single block of memory followed by a single
{{SSLWriteBuffer}} call and it resolves the problem. So since this is obviously
not a viable solution we need to figure out why the {{SSL_write}} calls are
being split up in such a strange way.
We had a second theory that was related to the BIO flush calls, so we made a
patch that would only call BIO flush once all the {{SSL_writes}} are complete
and that did not seem to resolve the problem, we had the same issue.
SSLNetVConnection: switch to a vectored write
-
Key: TS-3547
URL: https://issues.apache.org/jira/browse/TS-3547
Project: Traffic Server
Issue Type: Bug
Reporter: Thomas Jackson
UnixNetVConnection does a vectored write which bunches blocks together until
the outgoing buffer will fill up. This means we can better fill the packets,
and should give us a bit of a performance boost to SSL writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2490) traffic_cop kills TS process before it completes starting
[ https://issues.apache.org/jira/browse/TS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda reassigned TS-2490: - Assignee: Sudheer Vinukonda (was: Alan M. Carroll) traffic_cop kills TS process before it completes starting - Key: TS-2490 URL: https://issues.apache.org/jira/browse/TS-2490 Project: Traffic Server Issue Type: Bug Components: Cop, Core Reporter: David Carlin Assignee: Sudheer Vinukonda Labels: review, yahoo Fix For: 6.0.0 Attachments: TS-2490.diff Several things can slow traffic_server startup - Long remap.config file - Long list of certs in ssl_multicert.config (see TS-2058) - Plugins that take too long to initialize You end up with a race condition where traffic_server never starts because traffic_cop kills it before it completes. There was a hack at Yahoo to address this - a YTS setting proxy.config.watch_sleep_time to change the heartbeat interval as a workaround. Doesn't seem like a practical solution for issues like TS-2058 where the heartbeat would need to be in minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3548) psiginfo differs on illumos vs. Linux
[
https://issues.apache.org/jira/browse/TS-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3548:
Backport to Version: 5.3.0
psiginfo differs on illumos vs. Linux
-
Key: TS-3548
URL: https://issues.apache.org/jira/browse/TS-3548
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Eric Sproul
Assignee: James Peach
Fix For: 6.0.0
The arguments to psiginfo() are different on illumos platforms such as
OmniOS. This results in a build error:
{noformat}
CXXLDCompileParseRules
./CompileParseRules
CXX ParseRules.lo
CCLD mkdfa
signals.cc: In function 'void signal_format_siginfo(int, siginfo_t*, const
char*)':
signals.cc:162:21: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
psiginfo(info, msg);
^
In file included from ink_platform.h:104:0,
from libts.h:45,
from signals.cc:29:
/usr/include/siginfo.h:53:13: error: initializing argument 2 of 'void
psiginfo(siginfo_t*, char*)' [-fpermissive]
extern void psiginfo(siginfo_t *, char *);
^
gmake[3]: *** [signals.lo] Error 1
{noformat}
This happens with 5.2.1 as well as 5.3.0-rc2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3548) psiginfo differs on illumos vs. Linux
[
https://issues.apache.org/jira/browse/TS-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-3548.
-
Resolution: Fixed
Fix Version/s: 6.0.0
Assignee: James Peach
psiginfo differs on illumos vs. Linux
-
Key: TS-3548
URL: https://issues.apache.org/jira/browse/TS-3548
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Eric Sproul
Assignee: James Peach
Fix For: 6.0.0
The arguments to psiginfo() are different on illumos platforms such as
OmniOS. This results in a build error:
{noformat}
CXXLDCompileParseRules
./CompileParseRules
CXX ParseRules.lo
CCLD mkdfa
signals.cc: In function 'void signal_format_siginfo(int, siginfo_t*, const
char*)':
signals.cc:162:21: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
psiginfo(info, msg);
^
In file included from ink_platform.h:104:0,
from libts.h:45,
from signals.cc:29:
/usr/include/siginfo.h:53:13: error: initializing argument 2 of 'void
psiginfo(siginfo_t*, char*)' [-fpermissive]
extern void psiginfo(siginfo_t *, char *);
^
gmake[3]: *** [signals.lo] Error 1
{noformat}
This happens with 5.2.1 as well as 5.3.0-rc2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2591: -- Assignee: (was: Leif Hedstrom) Cache does not invalidate variant/alternate content types on PUT or POST - Key: TS-2591 URL: https://issues.apache.org/jira/browse/TS-2591 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Norm Paxton Fix For: 6.0.0 Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are: PUT, DELETE, POST. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 (This doesn't explicitly address variant content types, I read it as implied.) The current caching implementation only invalidates the Request URI, and not variant/alternate URI's. Example: A REST service provides both xml and json documents. A client app requests in both content-types (perhaps two different components, one expects xml, the other json). Assume both documents (xml and json) are in the cache. If the app PUTs a modification to the object in XML (ie, changes a User object's email address), it should then be able to retrieve the correct object data via a GET in json. In order to do so, the json object in the cache would need to be invalidated, so that the cache server forwards the request on to the REST service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508050#comment-14508050 ] Leif Hedstrom commented on TS-2591: --- I've lost whatever code was for this, not sure where we are with this unfortunately. Cache does not invalidate variant/alternate content types on PUT or POST - Key: TS-2591 URL: https://issues.apache.org/jira/browse/TS-2591 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Norm Paxton Assignee: Leif Hedstrom Fix For: 6.0.0 Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are: PUT, DELETE, POST. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 (This doesn't explicitly address variant content types, I read it as implied.) The current caching implementation only invalidates the Request URI, and not variant/alternate URI's. Example: A REST service provides both xml and json documents. A client app requests in both content-types (perhaps two different components, one expects xml, the other json). Assume both documents (xml and json) are in the cache. If the app PUTs a modification to the object in XML (ie, changes a User object's email address), it should then be able to retrieve the correct object data via a GET in json. In order to do so, the json object in the cache would need to be invalidated, so that the cache server forwards the request on to the REST service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3548) psiginfo differs on illumos vs. Linux
[
https://issues.apache.org/jira/browse/TS-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507980#comment-14507980
]
ASF subversion and git services commented on TS-3548:
-
Commit cb2ad69c0a3c3d9d5d9cb2a93f7210a3dda396de in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cb2ad69 ]
TS-3548: fix psiginfo usage on Illumos
psiginfo differs on illumos vs. Linux
-
Key: TS-3548
URL: https://issues.apache.org/jira/browse/TS-3548
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Eric Sproul
The arguments to psiginfo() are different on illumos platforms such as
OmniOS. This results in a build error:
{noformat}
CXXLDCompileParseRules
./CompileParseRules
CXX ParseRules.lo
CCLD mkdfa
signals.cc: In function 'void signal_format_siginfo(int, siginfo_t*, const
char*)':
signals.cc:162:21: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
psiginfo(info, msg);
^
In file included from ink_platform.h:104:0,
from libts.h:45,
from signals.cc:29:
/usr/include/siginfo.h:53:13: error: initializing argument 2 of 'void
psiginfo(siginfo_t*, char*)' [-fpermissive]
extern void psiginfo(siginfo_t *, char *);
^
gmake[3]: *** [signals.lo] Error 1
{noformat}
This happens with 5.2.1 as well as 5.3.0-rc2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build
[ https://issues.apache.org/jira/browse/TS-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508108#comment-14508108 ] Bin commented on TS-3427: - ping compilation error of atscppapi when configured for a out-of-tree build -- Key: TS-3427 URL: https://issues.apache.org/jira/browse/TS-3427 Project: Traffic Server Issue Type: Bug Components: Build, CPP API Reporter: Bin Assignee: Brian Geffon Fix For: 6.0.0 Attachments: atscppapi_3.diff, atscppapi_out_of_tree_2.diff, unused_variables.diff Header file not found error when --enable-cppapi is enabled for an out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3548) psiginfo differs on illumos vs. Linux
Eric Sproul created TS-3548:
---
Summary: psiginfo differs on illumos vs. Linux
Key: TS-3548
URL: https://issues.apache.org/jira/browse/TS-3548
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Eric Sproul
The arguments to psiginfo() are different on illumos platforms such as OmniOS.
This results in a build error:
{noformat}
CXXLDCompileParseRules
./CompileParseRules
CXX ParseRules.lo
CCLD mkdfa
signals.cc: In function 'void signal_format_siginfo(int, siginfo_t*, const
char*)':
signals.cc:162:21: error: invalid conversion from 'const char*' to 'char*'
[-fpermissive]
psiginfo(info, msg);
^
In file included from ink_platform.h:104:0,
from libts.h:45,
from signals.cc:29:
/usr/include/siginfo.h:53:13: error: initializing argument 2 of 'void
psiginfo(siginfo_t*, char*)' [-fpermissive]
extern void psiginfo(siginfo_t *, char *);
^
gmake[3]: *** [signals.lo] Error 1
{noformat}
This happens with 5.2.1 as well as 5.3.0-rc2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3549) configurable option to avoid thundering herd due to concurrent requests for the same object
[
https://issues.apache.org/jira/browse/TS-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3549:
--
Description:
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g manifest
files) or a complete cache miss (e.g segment files). ATS currently supports
different types of connection collapse (e.g. *read-while-write* functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*,
swr etc) but, in order for the *rww* to kick-in, ATS requires the complete
response headers for the object be received and validated. In other words,
until this happens, any number of incoming requests for the same object that
result in a cache miss or a cache stale would be forwarded to the origin. For a
scenario such as a live event, this leaves a sufficiently significant window,
where there could be 100's of requests being forwarded to the origin for the
same object. It has been observed during production that this results in
significant increase in latency for the objects waiting in read-while-write
state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get the
read lock for the object as configured. With these configured, ATS would retry
to get the read lock for as long and if it's still not available due to the
write lock being held by the first request that was forwarded to the origin
(for e.g. the response headers have not been received yet), then all the
waiting requests would simply be forwarded to the origin (by disabling cache
for each of them).
It is almost impossible to get the above settings accurate to help in all
possible situations (traffic, concurrent connections, network conditions etc).
Due to this reason, a configurable workaround is proposed below that avoids the
thundering herd completely. The patch below is mainly from [~jlaue] and
[~psudaemon] with some additional clean up, configuration control and debug
headers etc.
Basically, when configured, on failing to obtain a write lock for an object
(which means, there's another ongoing parallel request for the same object that
was forwarded to the origin), if it's a cache refresh miss, a stale copy of the
object is served, while if it's a complete cache miss, a *502* error is
returned to let the client (e.g. player) to reattempt. The *502* error also
includes a special internal ATS header named {{@ats-internal-messages}} with
the appropriate value to allow for custom logging or for plugins to take any
appropriate actions (e.g. prevent a fail-over if there's such a plugin that
does fail-over on a regular 502 error).
was:
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g manifest
files) or a complete cache miss (e.g segment files). ATS currently supports
different types of connection collapse (e.g. *read-while-write* functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*)
but, in order for this to kick-in, ATS requires the complete response headers
for the object be received and validated. In other words, until this happens,
any number of incoming requests for the same object that result in a cache miss
or a cache stale would be forwarded to the origin. For a scenario such as a
live event, this leaves a sufficiently significant window, where there could be
100's of requests being forwarded to the origin for the same object. It has
been observed during production that this results in significant increase in
latency for the objects waiting in read-while-write state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get the
read lock for the object as configured. With these configured, ATS would retry
to get the read lock for as long and if it's still not available due to the
write lock being held by the first request that was forwarded to the origin
(for
[jira] [Updated] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3550: -- Fix Version/s: 6.0.0 Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon Assignee: Leif Hedstrom Fix For: 6.0.0 traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508464#comment-14508464 ] Leif Hedstrom commented on TS-3550: --- I will close this in ~1 week assuming TS-3541 happens. Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon Assignee: Leif Hedstrom traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3550: - Assignee: Leif Hedstrom Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon Assignee: Leif Hedstrom traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3549) configurable option to avoid thundering herd due to concurrent requests for the same object
[
https://issues.apache.org/jira/browse/TS-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3549:
--
Description:
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g manifest
files) or a complete cache miss (e.g segment files). ATS currently supports
different types of connection collapse (e.g. *read-while-write* functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*)
but, in order for this to kick-in, ATS requires the complete response headers
for the object be received and validated. In other words, until this happens,
any number of incoming requests for the same object that result in a cache miss
or a cache stale would be forwarded to the origin. For a scenario such as a
live event, this leaves a sufficiently significant window, where there could be
100's of requests being forwarded to the origin for the same object. It has
been observed during production that this results in significant increase in
latency for the objects waiting in read-while-write state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get the
read lock for the object as configured. With these configured, ATS would retry
to get the read lock for as long and if it's still not available due to the
write lock being held by the first request that was forwarded to the origin
(for e.g. the response headers have not been received yet), then all the
waiting requests would simply be forwarded to the origin (by disabling cache
for each of them).
It is almost impossible to get the above settings accurate to help in all
possible situations (traffic, concurrent connections, network conditions etc).
Due to this reason, a configurable workaround is proposed below that avoids the
thundering herd completely. The patch below is mainly from [~jlaue] and
[~psudaemon] with some additional clean up, configuration control and debug
headers etc.
Basically, when configured, on failing to obtain a write lock for an object
(which means, there's another ongoing parallel request for the same object that
was forwarded to the origin), if it's a cache refresh miss, a stale copy of the
object is served, while if it's a complete cache miss, a *502* error is
returned to let the client (e.g. player) to reattempt. The *502* error also
includes a special internal ATS header named {{@ats-internal-messages}} with
the appropriate value to allow for custom logging or for plugins to take any
appropriate actions (e.g. prevent a fail-over if there's such a plugin that
does fail-over on a regular 502 error).
was:
When ATS is used as a delivery server for a video live streaming event, it's
possible that there are a huge number of concurrent requests for the same
object. Depending on the type of the object being requested, the cache lookup
for those objects can result in either a stale copy of the object (e.g manifest
files) or a complete cache miss (e.g segment files). ATS currently supports
different types of connection collapse (e.g. *read-while-write* functionality -
*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#read-while-writer*)
but, in order for this to kick-in, ATS requires the complete response headers
for the object be received and validated. In other words, until this happens,
any number of incoming requests for the same object that result in a cache miss
or a cache stale would be forwarded to the origin. For a scenario such as a
live event, this leaves a sufficiently significant window, where there could be
100's of requests being forwarded to the origin for the same object. It has
been observed during production that this results in significant increase in
latency for the objects waiting in read-while-write state.
Note that, there are also a couple of settings
*proxy.config.http.cache.open_read_retry_time* and
*proxy.config.http.cache.max_open_read_retries*
(*https://docs.trafficserver.apache.org/en/latest/admin/http-proxy-caching.en.html#open-read-retry-timeout*)
that can alleviate the thundering herd to some extent, by re-trying to get the
read lock for the object as configured. With these configured, ATS would retry
to get the read lock for as long and if it's still not available due to the
write lock being held by the first request that was forwarded to the origin
(for e.g. the response
[jira] [Comment Edited] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508461#comment-14508461 ] Leif Hedstrom edited comment on TS-3550 at 4/23/15 4:59 AM: You are using the interim cache? I don't think you will see any fixes for that feature, so I'd suggest just getting away from it and use bcache or dm-cache etc. https://issues.apache.org/jira/browse/TS-3541 was (Author: zwoop): You are using the interim cache? I don't think you will see any fixes for that feature, so I'd suggest just getting away from it and use bcache or dm-cache etc. Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3550) Segmentation fault (Address not mapped to object
[ https://issues.apache.org/jira/browse/TS-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508461#comment-14508461 ] Leif Hedstrom commented on TS-3550: --- You are using the interim cache? I don't think you will see any fixes for that feature, so I'd suggest just getting away from it and use bcache or dm-cache etc. Segmentation fault (Address not mapped to object - Key: TS-3550 URL: https://issues.apache.org/jira/browse/TS-3550 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 5.2.1 Reporter: daemon traffic_server: Segmentation fault (Address not mapped to object [0x2ae27800300a])traffic_server - STACK TRACE: /xxx/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x49e8f9] /lib64/libpthread.so.0(+0xf710)[0x2ae2d6cda710] /xxx/trafficserver/bin/traffic_server(_Z26dir_clean_range_interimvolllP15InterimCacheVol+0x8a)[0x6adeca] /xxx/trafficserver/bin/traffic_server(_ZN15InterimCacheVol24handle_recover_from_dataEiPv+0x44c)[0x6a37dc] /xxx/trafficserver/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x657845] /xxx/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x71dcb5] /xxx/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x57b)[0x71e54b] /xxx/trafficserver/bin/traffic_server[0x71d0fa] /lib64/libpthread.so.0(+0x79d1)[0x2ae2d6cd29d1] /lib64/libc.so.6(clone+0x6d)[0x2ae2d7cc98fd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3547) SSLNetVConnection writes each block separately to the socket
Thomas Jackson created TS-3547: -- Summary: SSLNetVConnection writes each block separately to the socket Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3547) SSLNetVConnection: switch to a vectored write
[ https://issues.apache.org/jira/browse/TS-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jackson updated TS-3547: --- Summary: SSLNetVConnection: switch to a vectored write (was: SSLNetVConnection writes each block separately to the socket) SSLNetVConnection: switch to a vectored write - Key: TS-3547 URL: https://issues.apache.org/jira/browse/TS-3547 Project: Traffic Server Issue Type: Bug Reporter: Thomas Jackson UnixNetVConnection does a vectored write which bunches blocks together until the outgoing buffer will fill up. This means we can better fill the packets, and should give us a bit of a performance boost to SSL writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
