[jira] [Updated] (TS-1058) Intercept an HTTP client's request

2011-12-25 Thread Yakov Kopel (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yakov Kopel updated TS-1058:


Description: 
I want that the trafficserver will give the client the response instead of the 
server.
The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not so 
convenience to use it.
I want to use the regular flow of the trafficserver, and its regular parsing 
commands.
The trafficserver's plugins examples also aren't using the INKHttpTxnIntercept 
, but they rather using the rasing error method, and then they response the 
request at the response hook.


So, this is whta i did.
On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised 
TS_EVENT_HTTP_ERROR.
I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http response 
with the KEEP-ALIVE header.
The problem is that the trafficserver is closing the connection although i 
added to the response the KEEP-ALIVE header.
 
When the Trafficserver is trying to send response to the client, it terminate 
the session after it.
Although I added the KEEP-ALIVE mime field - it didn't work.

The debug dump is looking like this:

  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::state_api_callback, HTTP_API_CONTINUE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::state_api_callout, HTTP_API_CONTINUE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
[HttpSM::do_redirect]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
[HttpTunnel::deallocate_postdata_copy_buffers]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] adding 
producer 'internal msg'
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] adding 
consumer 'user agent'
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) tunnel_run 
started, p_arg is NULL
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] 
consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session 
closed
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session 
destroy
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
[HttpTunnel::deallocate_postdata_copy_buffers]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling 
plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610


The Solution:

I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE, so 
the trafficserver will realy believe us that we want to keep this connection 
alive :)

Example for the usage of the new function:

  // Tell the trafficserver to not close this connection (keep-alive)
  TSHttpTxnCloseAfterResponse(txnp, 0);

  was:
When the Trafficserver is trying to send response to the client, it terminate 
the session after it.
Although I added the KEEP-ALIVE mime field - it didn't work.

The debug dump is looking like this:

  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::state_api_callback, HTTP_API_CONTINUE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::state_api_callout, HTTP_API_CONTINUE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
[HttpSM::do_redirect]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
[HttpTunnel::deallocate_postdata_copy_buffers]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] adding 
producer 'internal msg'
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] adding 
consumer 'user agent'
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) tunnel_run 
started, p_arg is NULL
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] 
consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session 
closed
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session 
destroy
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
[HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
[HttpTunnel::deallocate_postdata_copy_buffers]
  [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG:

[jira] [Updated] (TS-1059) prefetch segment fault

2011-12-25 Thread Zhao Yongming (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TS-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhao Yongming updated TS-1059:
--

Issue Type: Sub-task  (was: Bug)
Parent: TS-893

 prefetch segment fault
 --

 Key: TS-1059
 URL: https://issues.apache.org/jira/browse/TS-1059
 Project: Traffic Server
  Issue Type: Sub-task
  Components: HTTP
Affects Versions: 3.0.2
 Environment: linux(ubuntu)
Reporter: yunfei chen

 I encountered a segment faut when I was testing Prefetch module。
 ab -n 1 -c 1 -X 192.168.16.198:8080 -d 
 http://club.baobao.sohu.com/r-mmbb-3954004-0-29-900.html
 configuration in records.config
  CONFIG proxy.config.prefetch.prefetch_enabled INT 1
 configuration in prefetch.config
  prefetch_children 192.168.16.198
  html_tag img src
 #0  0x08124f17 in VIO::reenable (this=0x0) at 
 ../iocore/eventsystem/P_VIO.h:123
 #1  0x08147fe3 in KeepAliveConn::append (this=0xab9aef20, rdr=0x9c91b794) at 
 Prefetch.cc:1984
 #2  0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, 
 buf=0x9c91b780, reader=0x9c91b794) at Prefetch.cc:2039
 #3  0x0814679b in KeepAliveLockHandler::handleEvent (this=0xb23e0b30, 
 event=2, data=0x8ab2f60) at Prefetch.cc:2168
 #4  0x08104ba5 in Continuation::handleEvent (this=0xb23e0b30, event=2, 
 data=0x8ab2f60)
 at ../iocore/eventsystem/I_Continuation.h:146
 #5  0x0830a9f5 in EThread::process_event (this=0xb7396008, e=0x8ab2f60, 
 calling_code=2) at UnixEThread.cc:140
 #6  0x0830add5 in EThread::execute (this=0xb7396008) at UnixEThread.cc:217
 #7  0x0830900e in spawn_thread_internal (a=0x895eed8) at Thread.cc:88
 #8  0x00165cc9 in start_thread (arg=0xb6f91b70) at pthread_create.c:304
 #9  0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
 #0  0x08124f17 in VIO::reenable (this=0x0) at 
 ../iocore/eventsystem/P_VIO.h:123
 #1  0x08147fe3 in KeepAliveConn::append (this=0xa5736888, rdr=0x8d0b2f4) at 
 Prefetch.cc:1984
 #2  0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, 
 buf=0x8d0b2e0, reader=0x8d0b2f4) at Prefetch.cc:2039
 #3  0x08141db3 in PrefetchUrlBlaster::udpUrlBlaster (this=0x8abd3e0, 
 event=3300, data=0x0) at Prefetch.cc:885
 #4  0x0813e4ea in PrefetchUrlBlaster::init (this=0x8abd3e0, 
 list_head=0xabc59ac0, u_proto=TCP_BLAST) at Prefetch.h:280
 #5  0x08147806 in BlasterUrlList::invokeUrlBlaster (this=0xa7c22260) at 
 Prefetch.h:287
 #6  0x08141ac8 in BlasterUrlList::handleEvent (this=0xa7c22260, event=3302, 
 data=0xabc59ac0) at Prefetch.cc:803
 #7  0x08143c89 in PrefetchBlaster::handleEvent (this=0xa5739920, event=2, 
 data=0x0) at Prefetch.cc:1420
 #8  0x08144f42 in PrefetchBlaster::invokeBlaster (this=0xa5739920) at 
 Prefetch.cc:1769
 #9  0x08143e22 in PrefetchBlaster::handleEvent (this=0xa5739920, event=1102, 
 data=0xb23cdca0) at Prefetch.cc:1448
 #10 0x08104ba5 in Continuation::handleEvent (this=0xa5739920, event=1102, 
 data=0xb23cdca0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #11 0x082c1abf in CacheVC::callcont (this=0xb23cdca0, event=1102) at 
 P_CacheInternal.h:629
 #12 0x082c1487 in CacheVC::openReadStartHead (this=0xb23cdca0, event=3900, 
 e=0x0) at CacheRead.cc:1115
 #13 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=3900, 
 data=0x0) at ../iocore/eventsystem/I_Continuation.h:146
 #14 0x082c1431 in CacheVC::openReadStartHead (this=0xb23cdca0, event=2, 
 e=0x8ab48a0) at CacheRead.cc:1112
 #15 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=2, 
 data=0x8ab48a0)
 at ../iocore/eventsystem/I_Continuation.h:146
 #16 0x0830a9f5 in EThread::process_event (this=0xb7295008, e=0x8ab48a0, 
 calling_code=2) at UnixEThread.cc:140
 #17 0x0830add5 in EThread::execute (this=0xb7295008) at UnixEThread.cc:217
 #18 0x0830900e in spawn_thread_internal (a=0x895dd00) at Thread.cc:88
 #19 0x00165cc9 in start_thread (arg=0xb6e90b70) at pthread_create.c:304
 #20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

--
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-1063) prefetch resource leak

2011-12-25 Thread yunfei chen (Created) (JIRA) 
prefetch  resource leak
---

 Key: TS-1063
 URL: https://issues.apache.org/jira/browse/TS-1063
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.2
 Environment: linux（ubuntu）
Reporter: yunfei chen


configuration：
 records.config
   CONFIG proxy.config.prefetch.prefetch_enabled INT 1 
   CONFIG proxy.config.prefetch.default_url_proto STRING udp 
   CONFIG proxy.config.prefetch.default_data_proto STRING udp 
 prefetch.config
   prefetch child




[Dec 26 10:07:44.129] Server {2964810608} WARNING: too many connections, 
throttling
[Dec 26 10:17:44.176] Server {2964810608} WARNING: too many connections, 
throttling






FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 - 
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE: 
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 - 
insufficient memory
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 - 
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE: 
/usr/local/bin/traffic_server - STACK TRACE: 
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 - 
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE: 
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 - 
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE: 
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
  
 


 

#0  0x0012e416 in __kernel_vsyscall ()
#1  0x005c9941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x005cce42 in abort () at abort.c:92
#3  0x00520055 in __gnu_cxx::__verbose_terminate_handler() () from 
/usr/lib/libstdc++.so.6
#4  0x0051df35 in ?? () from /usr/lib/libstdc++.so.6
#5  0x0051df72 in std::terminate() () from /usr/lib/libstdc++.so.6
#6  0x0051e0e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0x0051e677 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#8  0x0051e74d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#9  0x081488fd in DynArraychar::resize (this=0x748ff4c, new_size=64) at 
../lib/ts/DynArray.h:174
#10 0x0815d5da in DynArraychar::operator() (this=0x748ff4c, idx=0) at 
../lib/ts/DynArray.h:122
#11 0x0815a9bb in HtmlParser::ScanHtmlForURL (this=0x748ff3c, r=0xbabb3ac0, 
url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1874
#12 0x0815a86a in HtmlParser::ParseHtml (this=0x748ff3c, r=0xbabb3ac0, 
url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1820
#13 0x08140816 in PrefetchTransform::parse_data (this=0x748fe88, 
reader=0xbabb3ac0) at Prefetch.cc:543
#14 0x0813ffe8 in PrefetchTransform::handle_event (this=0x748fe88, event=1, 
edata=0x5991b530) at Prefetch.cc:435
#15 0x08104ba5 in Continuation::handleEvent (this=0x748fe88, event=1, 
data=0x5991b530)
at ../iocore/eventsystem/I_Continuation.h:146
#16 0x0830a9f5 in EThread::process_event (this=0xb7497008, e=0x5991b530, 
calling_code=1) at UnixEThread.cc:140
#17 0x0830ac38 in EThread::execute (this=0xb7497008) at UnixEThread.cc:189
#18 0x0830900e in spawn_thread_internal (a=0x895df28) at Thread.cc:88
#19 0x00165cc9 in start_thread (arg=0xb7092b70) at pthread_create.c:304
#20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130


--
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