[jira] [Created] (TS-1078) trafficserver-3.1.1-unstable.tar.bz2 core dumps during load test

2012-01-12 Thread Alistair Stevenson (Created) (JIRA) 
trafficserver-3.1.1-unstable.tar.bz2 core dumps during load test


 Key: TS-1078
 URL: https://issues.apache.org/jira/browse/TS-1078
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.1.1
 Environment: Redhat linux with no plugins (although stack trace shows 
our plugin being called).  The tests were run with no plugin and exactly the 
same stack trace occurred.
Reporter: Alistair Stevenson
Priority: Blocker
 Fix For: 3.1.2


(gdb) bt
#0 ink_restore_signal_handler_frame (stack=0x7f2a67650490, len=value
optimized out, signalhandler_frame=2) at ink_stack_trace.cc:68
#1 ink_stack_trace_get (stack=0x7f2a67650490, len=value optimized out,
signalhandler_frame=2) at ink_stack_trace.cc:89
#2 0x7f2a682dcf7d in ink_stack_trace_dump (sighandler_frame=2) at
ink_stack_trace.cc:114
#3 0x004d2512 in signal_handler (sig=11) at signals.cc:222
#4 signal handler called
#5 ink_atomiclist_push (l=0x100bb0, item=0x72a9100) at ink_queue.cc:457
#6 0x0065800b in ProtectedQueue::enqueue (this=0x100bb0, e=value
optimized out, fast_signal=false) at ProtectedQueue.cc:53
#7 0x0062c3ca in NetVConnection::Handle::do_locked_io_close
(this=0x6e01830, lerrno=-1) at NetVConnection.cc:93
#8 0x00507608 in HttpServerSession::do_io_close (this=0x6e01770,
alerrno=value optimized out) at HttpServerSession.cc:122
#9 0x0050a78b in HttpSessionManager::acquire_session (this=0x941940,
cont=value optimized out, ip=0xa5443c0, hostname=0x5732c19
10.20.48.15, ua_session=value optimized out, sm=0xa543d20)
at HttpSessionManager.cc:257
#10 0x0051d544 in HttpSM::do_http_server_open (this=0xa543d20,
raw=false) at HttpSM.cc:4139
#11 0x0051e0e8 in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6464
#12 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#13 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1446
#14 0x00518499 in HttpSM::state_api_callback (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1265
#15 0x004a9af8 in TSHttpTxnReenable (txnp=value optimized out,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407
#16 0x7f2a63a3d45b in opwvPluginHandler (contp=0x7631780,
event=TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE, edata=0xa543d20) at
/bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi
c_server/plugin.cpp:82
#17 0x00516585 in HttpSM::state_api_callout (this=0xa543d20,
event=value optimized out, data=value optimized out) at
HttpSM.cc:1372
#18 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6353
#19 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#20 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1446
#21 0x00518499 in HttpSM::state_api_callback (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1265
#22 0x004a9af8 in TSHttpTxnReenable (txnp=value optimized out,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407
#23 0x7f2a63a3d6cc in opwvPluginHandler (contp=0x7631780,
event=TS_EVENT_HTTP_OS_DNS, edata=0xa543d20) at
/bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi
c_server/plugin.cpp:117
#24 0x00516585 in HttpSM::state_api_callout (this=0xa543d20,
event=value optimized out, data=value optimized out) at
HttpSM.cc:1372
#25 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6353
#26 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#27 0x0050d58a in HttpSM::do_hostdb_lookup (this=0xa543d20) at
HttpSM.cc:3749
#28 0x0051e72b in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6414
#29 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#30 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1446
#31 0x00518499 in HttpSM::state_api_callback (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1265
#32 0x004a9af8 in TSHttpTxnReenable (txnp=value optimized out,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407
#33 0x7f2a63a3d4eb in opwvPluginHandler (contp=0x7631780,
event=TS_EVENT_HTTP_POST_REMAP, edata=0xa543d20) at
/bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi
c_server/plugin.cpp:90
#34 0x00516585 in HttpSM::state_api_callout (this=0xa543d20,
event=value optimized out, data=value optimized out) at
HttpSM.cc:1372
#35 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6353
#36 0x0050b8ff in

[jira] [Commented] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.

2012-01-12 Thread Kevin Giles (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184964#comment-13184964
 ] 

Kevin Giles commented on TS-1073:
-

Yes, I'll have a go.

 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

 Attachments: TS-1073.patch


 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