[jira] [Issue Comment Edited] (TS-1072) No transactions per second available in traffic server 3.0
[ https://issues.apache.org/jira/browse/TS-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181450#comment-13181450 ] Steve Owens edited comment on TS-1072 at 1/6/12 5:25 PM: - Ah, after using sudo it works. I was thrown off by the fact I didn't get a permission denied error but the program behaved as if it ran normally but found no data. was (Author: steveo.disney): Ah, after using sudo it works. I was thrown off by the fact I didn't a permission denied error but the program behaved as if it ran normally but found no data. No transactions per second available in traffic server 3.0 -- Key: TS-1072 URL: https://issues.apache.org/jira/browse/TS-1072 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 3.0.1 Environment: CentOS 5.7 Reporter: Steve Owens The following command yields an error which is not in accordance with the currently available documentation for traffic server: /tmp /opt/trafficserver/bin/traffic_line -r proxy.node.http.user_agent_xacts_per_second /opt/trafficserver/bin/traffic_line: Variable Not Found How can we get the basic statistic related to how many transactions per second the traffic server is handling. This is needed for capacity planning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1072) No transactions per second available in traffic server 3.0
[ https://issues.apache.org/jira/browse/TS-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Owens resolved TS-1072. - Resolution: Fixed No issue just a confusing program behavior. Perhaps a little improvement in the program output would help make things less confusing. No transactions per second available in traffic server 3.0 -- Key: TS-1072 URL: https://issues.apache.org/jira/browse/TS-1072 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 3.0.1 Environment: CentOS 5.7 Reporter: Steve Owens The following command yields an error which is not in accordance with the currently available documentation for traffic server: /tmp /opt/trafficserver/bin/traffic_line -r proxy.node.http.user_agent_xacts_per_second /opt/trafficserver/bin/traffic_line: Variable Not Found How can we get the basic statistic related to how many transactions per second the traffic server is handling. This is needed for capacity planning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181480#comment-13181480 ] Leif Hedstrom commented on TS-1035: --- Brian: Would you mind incorporating Igor's suggestions into a new patch? EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Fix For: 3.1.2 Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1035: - Assignee: Leif Hedstrom EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181520#comment-13181520 ] James Peach commented on TS-1041: - I never knew that sa_len and friends was a BSD-ism. Will need to add some autoconf. PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet -- Key: TS-1041 URL: https://issues.apache.org/jira/browse/TS-1041 Project: Traffic Server Issue Type: Improvement Components: DNS Environment: Mac OS X 10.7 Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's sa_len field populated correctly. This patch guarantees to populate it to the correct value so that plugin authors can rely on that field when copying the TSHostLookupResultAddrGet() result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1041: --- Assignee: James Peach (was: Leif Hedstrom) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet -- Key: TS-1041 URL: https://issues.apache.org/jira/browse/TS-1041 Project: Traffic Server Issue Type: Improvement Components: DNS Environment: Mac OS X 10.7 Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's sa_len field populated correctly. This patch guarantees to populate it to the correct value so that plugin authors can rely on that field when copying the TSHostLookupResultAddrGet() result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1043) PATCH: teach TSFetchUrl to use the content-length to find the after_body event
[ https://issues.apache.org/jira/browse/TS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1043. - Resolution: Won't Fix Assignee: James Peach The proposed patch breaks the API as described in the previous comment. Resolving as WontFix. PATCH: teach TSFetchUrl to use the content-length to find the after_body event -- Key: TS-1043 URL: https://issues.apache.org/jira/browse/TS-1043 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Assignee: James Peach Fix For: 3.1.2 Attachments: 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch TSFetchUrl() does not fire the after_body event until the TCP connection is closed. The fix is to check the content-length when we receive more bytes and to fire the after_body event when all the byte are received. This looks like https://issues.apache.org/jira/browse/TS-817 and possibly https://issues.apache.org/jira/browse/TS-912 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Attachments: PluginVC.patch, PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1074: - Attachment: PluginVC.patch PluginVC.patch PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Attachments: PluginVC.patch, PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181723#comment-13181723 ] Leif Hedstrom commented on TS-1045: --- James: Do you want me to review and commit the patch in https://issues.apache.org/jira/secure/attachment/12509025/0001-Add-new-public-API-TSFetchHdrGet.patch ? PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0001-Add-new-public-API-TSFetchHdrGet.patch, 0007-Add-new-public-API-TSFetchHdrGet.patch, TS-1045-formatting.diff TSFetchUrl does not provide any way to get the headers from the result. This patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() and returns the headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1074: -- Fix Version/s: 3.1.2 PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1074: - Assignee: Leif Hedstrom PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1074. --- Resolution: Fixed Resolving this. Brian, would you mind going through the bug list, and close as duplicate(s) whatever bugs you think this actually fixes as well? PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181744#comment-13181744
]
Leif Hedstrom commented on TS-1073:
---
Hi Kevin!
Thanks for the bug, and patch. Would you mind attaching the patch as a real
attachement? It makes review (and commiting) it a lot easier.
Cheers,
-- Leif
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Fix For: 3.1.2
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1073:
--
Fix Version/s: 3.1.2
Assignee: Leif Hedstrom
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.2
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1008) TCP connection data isn't available from TSHttpSsn Object
[ https://issues.apache.org/jira/browse/TS-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181747#comment-13181747 ] Leif Hedstrom commented on TS-1008: --- Nick: Can we close this? TCP connection data isn't available from TSHttpSsn Object - Key: TS-1008 URL: https://issues.apache.org/jira/browse/TS-1008 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.1.2 TCP connection data can be obtained through several API functions, such as TSHttpTxnClientAddrGet. But the connection naturally belongs not to the TXN object but to the SSN object. There should be a TSHttpSsn*AddrGet family of functions that can be used in a SSN_START (or any later) hook to obtain connection information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1049: - Assignee: Leif Hedstrom TS hangs (dead lock) on HTTPS POST requests --- Key: TS-1049 URL: https://issues.apache.org/jira/browse/TS-1049 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Affects Versions: 3.1.1, 3.1.0, 3.0.2 Environment: RedHat Enterprise Linux 6.0, Intel 32-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 Attachments: records.config A very reproducible bug where the body of a HTTPS POST request is never forwarded to the origin server. Client submits a HTTPS POST request to TS, which is supposed to forward to the backend/origin server via HTTP. TS process the HTTP headers and establishes connection to the origin server, but the body of the HTTPS POST is never read. This hangs until the client times out and shuts down the connection. To reproduce: 1) Client connects to TS using HTTPS (works OK if it is just HTTP). 2) It must be a POST request. 3) TS must use at least 2 worker threads. 4) Easier to reproduce when the connections to the origin server is HTTP (not HTTPS). 5) POST body must be large enough so that the HTTP request headers and POST body do *NOT* fit within the same TCP packet. (2000 bytes is a good size) 6) I can consistently reproduce this problem using 2 separate clients each simultaneously submitting 2 requests back to back (i.e., 2 requests from each client, a total of 4 requests). This gives you a high probability that at least one of the requests would hang. Observation: 1) Thread A accepted and processed the HTTP headers, and called UnixNetProcessor::connect_re to prepare a new connection to the origin server. 2) Thread A must not have read the body of the POST. Otherwise, it works fine. 3) Thread B was assigned the task to handle the origin server connection. If the same thread A was picked, then everything works fine. 4) Apparently, one of the first things that thread B does is to acquire the mutex for reading from the client. (Why does it do that??) 5) While thread B was holding the mutex, thread A proceeded in SSLNetVConnection::net_read_io, tried and failed to acquire the mutex. Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but gave up after the second failure. But if thread B released the mutex soon enough, that thread A could proceed happily and everything works. 6) From this point, the body of the POST is never read from the client, and there is nothing to be proxy'd to the origin server, and both the consumer and producer tasks are never scheduled to run again -- or until the client times out. I tried setting the client-side time out to as long as 3-5 minutes and TS really does not recover by itself until the client closed the connection. This is the first time I uses this bug system. Please let me know how I could produce the configuration files and trace logs, etc. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181861#comment-13181861 ] Leif Hedstrom commented on TS-1049: --- Interesting.Did you try turning off sharing origin connections (or setting it to 2, which creates a connection pool per thread)? Not saying that's a fix, but curious to hear if it helps (and if it does, it's a viable work around). I'll also look at your suggested patch, and see if it makes sense :) Thanks! -- leif TS hangs (dead lock) on HTTPS POST requests --- Key: TS-1049 URL: https://issues.apache.org/jira/browse/TS-1049 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Affects Versions: 3.1.1, 3.1.0, 3.0.2 Environment: RedHat Enterprise Linux 6.0, Intel 32-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 Attachments: records.config A very reproducible bug where the body of a HTTPS POST request is never forwarded to the origin server. Client submits a HTTPS POST request to TS, which is supposed to forward to the backend/origin server via HTTP. TS process the HTTP headers and establishes connection to the origin server, but the body of the HTTPS POST is never read. This hangs until the client times out and shuts down the connection. To reproduce: 1) Client connects to TS using HTTPS (works OK if it is just HTTP). 2) It must be a POST request. 3) TS must use at least 2 worker threads. 4) Easier to reproduce when the connections to the origin server is HTTP (not HTTPS). 5) POST body must be large enough so that the HTTP request headers and POST body do *NOT* fit within the same TCP packet. (2000 bytes is a good size) 6) I can consistently reproduce this problem using 2 separate clients each simultaneously submitting 2 requests back to back (i.e., 2 requests from each client, a total of 4 requests). This gives you a high probability that at least one of the requests would hang. Observation: 1) Thread A accepted and processed the HTTP headers, and called UnixNetProcessor::connect_re to prepare a new connection to the origin server. 2) Thread A must not have read the body of the POST. Otherwise, it works fine. 3) Thread B was assigned the task to handle the origin server connection. If the same thread A was picked, then everything works fine. 4) Apparently, one of the first things that thread B does is to acquire the mutex for reading from the client. (Why does it do that??) 5) While thread B was holding the mutex, thread A proceeded in SSLNetVConnection::net_read_io, tried and failed to acquire the mutex. Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but gave up after the second failure. But if thread B released the mutex soon enough, that thread A could proceed happily and everything works. 6) From this point, the body of the POST is never read from the client, and there is nothing to be proxy'd to the origin server, and both the consumer and producer tasks are never scheduled to run again -- or until the client times out. I tried setting the client-side time out to as long as 3-5 minutes and TS really does not recover by itself until the client closed the connection. This is the first time I uses this bug system. Please let me know how I could produce the configuration files and trace logs, etc. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181863#comment-13181863 ] Leif Hedstrom commented on TS-981: -- I'm curious if you have only got this to reproduce in transparent proxy, or if it happens in reverse or forward proxy as well? Also, can you reproduce it with a debug build? It would (hopefully) have more information. ATS as transparent proxy crashes under heavy load - Key: TS-981 URL: https://issues.apache.org/jira/browse/TS-981 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support. ATS compiled as: ./configure --enable-tproxy --enable-libev Reporter: Danny Shporer Priority: Critical Fix For: 3.1.2 Attachments: records.config ATS crashes under heavy load testing - around 25,000 HTTP transactions per second. I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. GDB info: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42174940 (LWP 6663)] 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 536 fd_change(event_loop-eio, eio.fd, 0); (gdb) bt #0 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 #1 NetHandler::mainNetEvent (this=0x2b12c628, event=value optimized out, e=value optimized out) at UnixNet.cc:432 #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, e=0xf44570, calling_code=5) at I_Continuation.h:146 #3 0x006c055c in EThread::execute (this=0x2b12b010) at UnixEThread.cc:262 #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 (gdb) info f Stack level 0, frame at 0x42174030: rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f inlined into frame 1 source language c++. Arglist at unknown address. Locals at unknown address, Previous frame's sp in rsp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181865#comment-13181865
]
Leif Hedstrom commented on TS-980:
--
Is this ready for review? If so, please assign it to me, and I'll take a look.
Thanks!
-- leif
change client_session schedule from global to thread local, and reduce the
try_locks in UnixNetVConnection::reenable
-
Key: TS-980
URL: https://issues.apache.org/jira/browse/TS-980
Project: Traffic Server
Issue Type: Improvement
Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
Environment: all
Reporter: weijin
Assignee: weijin
Fix For: 3.1.2
Attachments: ts-980.diff
I did some performance test on ats last days(disable cache, set share_server
session 2, pure proxy mode), I did see significant improvement on low load,
but it dropped rapidly when load is high. meanwhile, some stability problems
happened. Through gdb, I found the client_session`s mutex can be acquired by
two or more threads, I believe some schedules happened during the sm
life_time. May be we need do some work to find these eventProcessor.schedules
and change them to thread schedules.
UnixVConnecton::reenable {
if (nh-mutex-thread_holding == t) {
// put into ready_list
} else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
// put into enable_list;
} else {
// put into ready_list;
}
}
remove UnixNetVConnection::reenable try_lock operations, 3 reasons
1. try_lock operation means obj allocation and deallocation operation.
frequently
2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule
by as soon as possible)
3. try_lock should not acquire the net-handler`s mutex. That may lead more
net io latency if it is an epoll event need to be processed in other threads.
If it is not an epoll event(time event), I don`t think putting vc in
ready_list has any advantage than in enable_list.
may be we can change reenale function like this:
UnixVConnecton::reenable {
if (nh-mutex-thread_holding == t) {
// put into ready_list;
} else {
// put into enable_list;
}
my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1036) Improve squid log compatibility
[ https://issues.apache.org/jira/browse/TS-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1036: -- Fix Version/s: (was: 3.1.2) 3.1.3 Improve squid log compatibility Key: TS-1036 URL: https://issues.apache.org/jira/browse/TS-1036 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Fix For: 3.1.3 See https://github.com/mnot/squidpeek/commit/3874cb902f257974d16c8eae5fc5a77c6fafbf69 for some differences, from mnot as well: all of the ERR_* ones squid does TCP_REFRESH_FAIL_HIT, you do TCP_REF_FAIL_HIT squid does TCP_CLIENT_REFRESH_MISS, you do TCP_CLIENT_REFRESH squid does TCP_SWAPFAIL_MISS, you do TCP_SWAPFAIL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-993: - Fix Version/s: (was: 3.1.2) 3.1.3 Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Assignee: Leif Hedstrom Fix For: 3.1.3 Attachments: 0001-Add-OpenBSD-support.patch Add OpenBSD support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1053:
--
Fix Version/s: (was: 3.1.2)
3.1.3
get combo_handler compiled
--
Key: TS-1053
URL: https://issues.apache.org/jira/browse/TS-1053
Project: Traffic Server
Issue Type: Task
Components: Plugins
Reporter: Conan Wang
Fix For: 3.1.3
Attachments: Makefile, combo_handler.diff, fetcher.diff
combo_handler require ESI's code. Before make ESI work as a lib, you can try
it this way:
make esi/lib and esi/fetcher the subdir of combo_handler and use the
makefile.
{noformat}
combo_handler
|combo_handler.cc
|fetcher
|lib
|LICENSE
|Makefile
|README
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-801) Crash Report: enable update will triger Segmentation fault
[
https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-801:
-
Fix Version/s: (was: 3.1.2)
3.1.3
Crash Report: enable update will triger Segmentation fault
--
Key: TS-801
URL: https://issues.apache.org/jira/browse/TS-801
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.8
Environment: v2.1.8 and update function enabled.
Reporter: Zhao Yongming
Labels: update
Fix For: 3.1.3
{code}
b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation
fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
b13621367...@hotmail.com:
/usr/local/ts/bin/traffic_server[0x5260c9]
/lib64/libpthread.so.0[0x3088e0f4c0]
[0x6e]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x6e)[0x57e0e2]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com:
8)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::state_add_to_list(int,
void*)+0x2aa)[0x56a51c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x2cb)[0x570c13]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
HTTPHdr*)+0x168)[0x5b5c1c]
/usr/local/ts/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x335)[0x53599f]
/usr/local/ts/bin/traffic_server(UpdateSM::HandleSMEvent(int,
Event*)+0x1ab)[0x535437]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x12c)[0x6fa9dc]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x9b)[0x6fabef]
/usr/local/ts/bin/traffic_server[0x6f9b4c]
/lib64/libpthread.so.0[0x3088e077e1]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[LocalManager::-PollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[Alarms::-SignalAlarm] Server Process was reset
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[May 26 16:25:15.577] Manager {140030245394400} NOTE:
[LocalManager::-StartProxy] Launching ts process
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2
[
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-832:
-
Fix Version/s: (was: 3.1.2)
3.1.3
Crash Report: RecMessageMarshal_Realloc in cluster mode 2
-
Key: TS-832
URL: https://issues.apache.org/jira/browse/TS-832
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core
Affects Versions: 3.1.0
Environment: version trunk, aka v3.0 after, cluster mode set to 2(
management cluster ), --enable-debug
Reporter: Zhao Yongming
Labels: cluster, realloc
Fix For: 3.1.3
here is two core dumps:
{code}
#0 0x003c33030265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003c33030265 in raise () from /lib64/libc.so.6
#1 0x003c33031d10 in abort () from /lib64/libc.so.6
#2 0x003c3306a84b in __libc_message () from /lib64/libc.so.6
#3 0x003c33075421 in realloc () from /lib64/libc.so.6
#4 0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2acf29248f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x20034150, event=1,
e=0x20033d30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x20034150,
event=1, data=0x20033d30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at
Thread.cc:88
#11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x41f4c3e0:
rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
called by frame at 0x41f4c520
Arglist at 0x41f4c3d0, args:
Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
Saved registers:
rip at 0x41f4c3d8
{code}
{code}
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
#1 0x0038aa231d10 in abort () from /lib64/libc.so.6
#2 0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
#3 0x0038aa275421 in realloc () from /lib64/libc.so.6
#4 0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2ab280680f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1,
e=0x16a6ed30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x16a6f150,
event=1, data=0x16a6ed30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at
Thread.cc:88
#11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x406b03e0:
rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
called by frame at 0x406b0520
Arglist at 0x406b03d0, args:
Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
Saved registers:
rip at 0x406b03d8
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-902) Crash report: invalid ip range in remap.config crash server
[
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-902:
-
Fix Version/s: (was: 3.1.2)
3.1.3
Crash report: invalid ip range in remap.config crash server
---
Key: TS-902
URL: https://issues.apache.org/jira/browse/TS-902
Project: Traffic Server
Issue Type: Bug
Components: Configuration, HTTP
Affects Versions: 3.1.0, 3.0.1
Environment: TS 3.0.1
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.1.3
when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip
filtering, it will cause the server crash:
{code}
[TrafficServer] using root directory '/usr'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm]
Server Process born
[Aug 4 11:04:54.222] {46990117603664} STATUS: opened
/var/log/trafficserver/diags.log
[Aug 4 11:04:54.224] {46990117603664} NOTE: updated diags config
[Aug 4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7],
logging_mode = 1
[Aug 4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor:
Started the prefetch processor
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at
line #1; Aborting!
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable
to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
FATAL: [ReverseProxy] Unable to parse IP value in
src_ip=128.0.0.0-121.14.89.0 at line 1
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
/usr/bin/traffic_server(main+0xc07)[0x4bf177]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
/usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
[Aug 4 11:04:54.506] Manager {140564987967264} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
{code}
and here is the rules defined in my remap.config:
{code}
.defflt tools @action=deny @src_ip=0.0.0.0-127.0.0.0
@src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255
@method=PURGE
.useflt tools
{code}
well, it is invalid, but we should not crash, right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-920) HTTP CONNECT gives bad request line
[ https://issues.apache.org/jira/browse/TS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-920: - Fix Version/s: (was: 3.1.2) 3.1.3 HTTP CONNECT gives bad request line --- Key: TS-920 URL: https://issues.apache.org/jira/browse/TS-920 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: M. Nunberg Fix For: 3.1.3 An HTTP CONNECT tunnel request such as: CONNECT foo.com:443 HTTP/1.1 is translated into: CONNECT https://foo.com:443/ HTTP/1.1 and is sent as such to a parent proxy when ATS is configured to forward requests to parent proxy. This can break the parent proxy in some (all?) cases, since the semi-standard for CONNECT is a host specification, not a URI. In practice, for most applications, this issue is quite rare since it is often pointless to forward CONNECT requests, unless the parent proxy does some special handling or man-in-the-middle operations etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
