[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=13182218#comment-13182218 ] Danny Shporer commented on TS-981: -- Yes I was. It's mentioned in the Environment field of the bug report details that ATS is compiled with --enable-libev. I did not find anywhere any mention that it has been removed. Anyway, when I realized that there was an exception in the libev code, I reverted to using epoll and that seems to work penfing bug report TS-1075. If libev is not supported by ATS then I guess you can close this bug. I would suggest to make it clear not to use it (maybe remove README.libev from the code distributable). 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] [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: 3.3.0 Assignee: (was: Leif Hedstrom) Moving out to v3.3.0, please move back if/when you have fixes for this. 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 Fix For: 3.3.0, 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-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1033: -- Fix Version/s: (was: 3.1.2) 3.1.3 Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 And of course various other places (including InkAPI). -- 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-1046) Add possibility to extend tsxs command line for -Iincludes
[ https://issues.apache.org/jira/browse/TS-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1046: -- Backport to Version: 3.0.3 (was: 3.0.2) Moving to 3.0.3, I don't think think this got into 3.0.2, right ? Add possibility to extend tsxs command line for -Iincludes -- Key: TS-1046 URL: https://issues.apache.org/jira/browse/TS-1046 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 3.1.1, 3.0.2 Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.1.2 Already commited in r1212075 -- 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-1060) fail assert at CacheVC::handleReadDone
[
https://issues.apache.org/jira/browse/TS-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1060:
--
Fix Version/s: (was: 3.0.2)
3.1.3
fail assert at CacheVC::handleReadDone
--
Key: TS-1060
URL: https://issues.apache.org/jira/browse/TS-1060
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 3.0.1
Environment: v3.0.x, with some patch from taobao
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Labels: crash
Fix For: 3.1.3
{code}
#0 0x003f96032a45 in raise () from /lib64/libc.so.6
#1 0x003f96034225 in abort () from /lib64/libc.so.6
#2 0x2b0dea6f6394 in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b0dea6f6466 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x2b0deb9ed240 Cache.cc:1959: failed assert `((Doc *)
buf-data())-magic == DOC_MAGIC`, ap=0x2b0deb9ed140) at ink_error.cc:65
#4 0x2b0dea6f6531 in ink_fatal (return_code=1,
message_format=0x2b0deb9ed240 Cache.cc:1959: failed assert `((Doc *)
buf-data())-magic == DOC_MAGIC`) at ink_error.cc:73
#5 0x2b0dea6f4ece in _ink_assert (a=0x773770 ((Doc *)
buf-data())-magic == DOC_MAGIC, f=0x7726be Cache.cc, l=1959) at
ink_assert.cc:44
#6 0x0069429a in CacheVC::handleReadDone (this=0x3d51710,
event=3900, e=0x0) at Cache.cc:1959
#7 0x004e02fa in Continuation::handleEvent (this=0x3d51710,
event=3900, data=0x0) at ../iocore/eventsystem/I_Continuation.h:146
#8 0x006b7715 in Cache::open_read (this=0x3aeaf00,
cont=0x2b0e20737fa8, key=0x2b0deb9ed9c0, request=0x2b0e207365d0,
params=0x2b0e20735e08,
type=CACHE_FRAG_TYPE_HTTP,
hostname=0x2b0e300458cb
img01.taobaocdn.combao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpgimg01.taobaocdn.comhttp://img01.taobaocdn.com/bao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpg;,
host_len=19) at CacheRead.cc:231
#9 0x0069cfcf in Cache::open_read (this=0x3aeaf00,
cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0,
params=0x2b0e20735e08,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1080
#10 0x0069a9f6 in CacheProcessor::open_read (this=0xf44d30,
cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0,
params=0x2b0e20735e08,
pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3041
#11 0x0055937c in HttpCacheSM::do_cache_open_read
(this=0x2b0e20737fa8) at HttpCacheSM.cc:220
#12 0x005594cd in HttpCacheSM::open_read (this=0x2b0e20737fa8,
url=0x2b0e207365e8, hdr=0x2b0e207365d0, params=0x2b0e20735e08, pin_in_cache=0)
at HttpCacheSM.cc:252
#13 0x0057802d in HttpSM::do_cache_lookup_and_read
(this=0x2b0e20735d10) at HttpSM.cc:3911
#14 0x005808d6 in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6455
#15 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#16 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#17 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#18 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#19 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#20 0x00580391 in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6396
#21 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#22 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#23 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#24 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#25 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
#26 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at
HttpSM.cc:1519
#27 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at
HttpSM.cc:502
#28 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at
HttpSM.cc:6380
#29 0x005801fa in HttpSM::call_transact_and_set_next_state
(this=0x2b0e20735d10, f=0x58f002
HttpTransact::ModifyRequest(HttpTransact::State*))
at HttpSM.cc:6346
#30 0x0056d45a in HttpSM::state_read_client_request_header
(this=0x2b0e20735d10, event=100, data=0x2b0e440157c8) at HttpSM.cc:783
#31 0x0056caf5 in HttpSM::setup_client_read_request_header
(this=0x2b0e20735d10) at HttpSM.cc:645
#32 0x0056f74c in
[jira] [Updated] (TS-990) IPv6 support for clustering
[ https://issues.apache.org/jira/browse/TS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-990: - Fix Version/s: (was: 3.1.2) 3.1.3 IPv6 support for clustering --- Key: TS-990 URL: https://issues.apache.org/jira/browse/TS-990 Project: Traffic Server Issue Type: Improvement Components: Clustering Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: clustering, ipv6 Fix For: 3.1.3 Update clustering to be IPv6 compatible. -- 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-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1058:
--
Fix Version/s: (was: 3.1.2)
3.1.3
Intercept an HTTP client's request
--
Key: TS-1058
URL: https://issues.apache.org/jira/browse/TS-1058
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Labels: patch
Fix For: 3.1.3
Attachments: patch.diff
Original Estimate: 24h
Remaining Estimate: 24h
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);
--
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-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1019:
--
Fix Version/s: (was: 3.1.2)
3.1.3
clean up access to librecords and remove wrappers
-
Key: TS-1019
URL: https://issues.apache.org/jira/browse/TS-1019
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Bryan Call
Assignee: Igor Galić
Priority: Minor
Fix For: 3.1.3
There are unneeded define wrappers around the librecord function calls:
{noformat}
[bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
* | grep define
iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
REC_ConfigReadInteger
proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
REC_ConfigReadInteger
proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
{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-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-981: - Fix Version/s: (was: 3.1.2) 3.1.3 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.3 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] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1015: -- Fix Version/s: (was: 3.1.2) 3.1.3 TSEvent is widely declared as int - Key: TS-1015 URL: https://issues.apache.org/jira/browse/TS-1015 Project: Traffic Server Issue Type: Bug Reporter: Nick Kew Priority: Minor Fix For: 3.1.3 TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is declared as type int. This makes it harder to follow/debug using tools like *trace or gdb. This may usefully be fixed as and when people encounter instances of it. -- 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-995) Change IPv6 support function names to be clearer and more compliant.
[ https://issues.apache.org/jira/browse/TS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-995: - Fix Version/s: (was: 3.1.2) 3.1.3 Change IPv6 support function names to be clearer and more compliant. Key: TS-995 URL: https://issues.apache.org/jira/browse/TS-995 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.1.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: 3.1.3 Several changes: 1) Change ink_inet to ats_ip. 2) Except for a few test functions, ats_is_ip, ats_is_ip4, ats_is_ip6. 3) Change the current cmp and eq functions to cmp_addr and eq_addr to reduce confusion about whether the port is compared as well. -- 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-561) Origin-server side IPv6 support
[ https://issues.apache.org/jira/browse/TS-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-561: - Fix Version/s: (was: 3.1.2) 3.1.3 Origin-server side IPv6 support --- Key: TS-561 URL: https://issues.apache.org/jira/browse/TS-561 Project: Traffic Server Issue Type: New Feature Components: Network Environment: Linux 4.x Reporter: Anirban Roy Assignee: Alan M. Carroll Fix For: 3.1.3 raffic Server used as forward proxy in a number of places including web crawling and feed fetching applications. In those applications, (origin)server side IPv6 support is desirable. As the Internet running out of IPv4 addresses, the new sites will run on IPv6 stack. The applications pulling content using traffic server should be able to do so in the changing scenario. -- 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-977) RecCore usage cleanup
[
https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-977:
-
Fix Version/s: (was: 3.1.2)
3.1.3
RecCore usage cleanup
-
Key: TS-977
URL: https://issues.apache.org/jira/browse/TS-977
Project: Traffic Server
Issue Type: Task
Components: Cleanup
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.3
in RecCore.*
{code}
int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
//-
// RecGetRecordXXX
//-
int
RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
{
int err;
RecData data;
if ((err = RecGetRecord_Xmalloc(name, RECD_INT, data, lock)) ==
REC_ERR_OKAY)
*rec_int = data.rec_int;
return err;
}
{code}
and there is something heavy used:
{code}
//-
// Backwards Compatibility Items (REC_ prefix)
//-
#define REC_ReadConfigInt32(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, (RecInt*) tmp); \
_var = (int32_t)tmp; \
} while (0)
#define REC_ReadConfigInteger(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, tmp); \
_var = tmp; \
} while (0)
{code}
and a real case, the REC_ReadConfigInteger is renamed to
IOCORE_ReadConfigInteger:
{code}
RecInt cache_config_threads_per_disk = 12;
#define IOCORE_ReadConfigIntegerREC_ReadConfigInteger
IOCORE_ReadConfigInteger(cache_config_threads_per_disk,
proxy.config.cache.threads_per_disk);
{code}
my question is, why it is so complex in all these renaming? why not just:
{code}
RecGetRecordInt(proxy.config.cache.threads_per_disk,
cache_config_threads_per_disk);
{code}
brief talk with Leif, we may need to cleanup the use of REC_*. make it a
small task here
--
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-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)
[
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-968:
-
Fix Version/s: (was: 3.1.2)
3.1.3
During/after daily logfile roll, trafficserver seg faults (Sig 11)
--
Key: TS-968
URL: https://issues.apache.org/jira/browse/TS-968
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.0.1
Environment: Ubuntu 10.10, 2.6.35-24-virtual
Reporter: Drew Rothstein
Fix For: 3.1.3
Every day at 00:00:00 after/during the log file roll, I see a segfault. Here
are the past couple days:
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/error.log was rolled to
/usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/squid.log was rolled to
/usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/extended2.log was rolled to
/usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
[Sep 22 00:00:17.729] Manager {140722071643936} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Sep 22 00:00:17.729] Manager {140722071643936} FATAL: (last system error
104: Connection reset by peer)
[Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Sep 22 00:00:17.730] Manager {140722071643936} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Sep 22 00:00:17.730] Manager {140722071643936} ERROR: (last system error
32: Broken pipe)
[E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
[Sep 22 00:00:17.786] {140131209512736} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.35-24-virtual'
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup
complete
[Sep 22 00:00:18.827] Manager {140131209512736} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr/local'
[Sep 22 00:00:18.849] Manager {140131209512736} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm]
Server Process born
[Sep 22 00:00:19.874] {47510015031936} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
[Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
[Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
[Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7],
logging_mode = 3
[Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
[Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/error.log was rolled to
/usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/squid.log was rolled to
/usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/extended2.log was rolled to
/usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
[Sep 23 00:00:14.668] Manager {140131209512736} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Sep 23 00:00:14.668] Manager {140131209512736} FATAL: (last system error
104: Connection reset by peer)
[Sep 23 00:00:14.668] Manager {140131209512736} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[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=13182309#comment-13182309 ] Leif Hedstrom commented on TS-1049: --- Reading the code for the normal NetVC, and the SSL NetVC, I'm fairly certain your suggestion is correct. Thanks! 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] [Resolved] (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 resolved TS-1049. --- Resolution: Fixed Great job Wilson! 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-996) HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called
[ https://issues.apache.org/jira/browse/TS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182313#comment-13182313 ] Leif Hedstrom commented on TS-996: -- I think the V2 patch is missing some changes (the header definitions for sure). Can you please update with a new patch, and I'll review it. Thanks! HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called Key: TS-996 URL: https://issues.apache.org/jira/browse/TS-996 Project: Traffic Server Issue Type: Bug Components: HTTP, MIME Affects Versions: 3.1.0 Reporter: B Wyatt Fix For: 3.1.2 Attachments: m_host.V2.patch, m_host.patch class HTTPHdr stores a copy of the string pointer from either the URLimpl or the MIMEHdr for the host name in m_host. In both cases, these strings can be moved to a new heap underneath the HTTPHdr. When this happens, the process will, at best read stale memory and be fine and at worst read unmapped memory and segfault. Currently, HdrHeap::evacuate_from_str_heaps is called to coalesce multiple heaps into a single heap. When this happens it will directly access the low level objects via ::move_strings calls. These objects do not posses the necessary information to inform parent objects about the change, nor does the HdrHeap directly inform interested parties. -- 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-996) HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called
[ https://issues.apache.org/jira/browse/TS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-996: Assignee: Leif Hedstrom HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called Key: TS-996 URL: https://issues.apache.org/jira/browse/TS-996 Project: Traffic Server Issue Type: Bug Components: HTTP, MIME Affects Versions: 3.1.0 Reporter: B Wyatt Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: m_host.V2.patch, m_host.patch class HTTPHdr stores a copy of the string pointer from either the URLimpl or the MIMEHdr for the host name in m_host. In both cases, these strings can be moved to a new heap underneath the HTTPHdr. When this happens, the process will, at best read stale memory and be fine and at worst read unmapped memory and segfault. Currently, HdrHeap::evacuate_from_str_heaps is called to coalesce multiple heaps into a single heap. When this happens it will directly access the low level objects via ::move_strings calls. These objects do not posses the necessary information to inform parent objects about the change, nor does the HdrHeap directly inform interested parties. -- 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-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1002:
--
Fix Version/s: (was: 3.1.2)
3.1.4
This is unfortunately how it works (currently). I'm thinkign, we might want to
make a copy of the pristine request header object before remapping, clean out
all the code around logging the pristine data, and add another directive to
logging to get components out of this (new) pristine host header object.
Moving this out to 3.1.4 for now.
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: Wish
Components: Logging
Reporter: Conan Wang
Priority: Minor
Fix For: 3.1.4
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
[ https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1038: - Assignee: Leif Hedstrom (was: William Bardwell) TSHttpTxnErrorBodySet() can leak memory (pt 2) -- Key: TS-1038 URL: https://issues.apache.org/jira/browse/TS-1038 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: TSHttpTxnErrorBodySet.patch TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 which frees internal_msg_buffer_type...it's expected that mimetype was malloced since clearly it's being freed. So that means there is still a memory leak in TSHttpTxnErrorBodySet(). Patch 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-1062) TSFetchUrl doesn't handle chunked encoding
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1062: - Assignee: James Peach TSFetchUrl doesn't handle chunked encoding -- Key: TS-1062 URL: https://issues.apache.org/jira/browse/TS-1062 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Fix For: 3.1.2 If you use TSFetchUrl() to fetch a resource and the response comes back with chunked encoding, you are basically hosed. The caller never gets the SUCCESS event because FetchSM does not know how to decode the body. There's no content-length header and the origin server doesn't drop the TCP connection, so we just sit there waiting for the response to finish forever (well until the origin server drops the connection 10s later). -- 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-921) TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the Transfer Encoding: chunked http header !
[
https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-921:
-
Fix Version/s: (was: 3.1.2)
3.1.3
Looking for someone who wish to work on this (if so, just take it / assign it).
Moving out unassigned bugs with no patches etc. to 3.1.3 for now.
TSIOBufferBlockReadStart() could'nt return the corresponding chunk data
length when original server using the Transfer Encoding: chunked http
header !
Key: TS-921
URL: https://issues.apache.org/jira/browse/TS-921
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.0.1
Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1,
Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G,
HardDisk: 500G
Reporter: taoyunxing
Labels: transfer_encoding_chunded
Fix For: 3.1.3
Original Estimate: 672h
Remaining Estimate: 672h
Recently I meet with a strange proble when I manage to get the server
response body in the Transfer Encoding: chunked mode:
I couldn't get the corresponding chunk length in hexdecimal ! The details as
follows:
I use the null-transform plugin modified to just output the server response
body, when the web server uses the Transfer Encoding: chunked header
to transfer chunked data to user agent, eg, I request the web page:
http://www.qq.com/;, I just get the chunk body data, but get no chunk length
in
the hexdecimal format 383cb\r\n before the chunk body data. the chunk body
data is uncompressed and like as !DOCTYPE html PUBLIC -//W3C//DTD XHTML
1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n...
In addition, I capture the data packet using the Wireshark software, I sure
that I see the chunk length 383cb\r\n before the chunk body data
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n..., it is
a complete chunk response !
I continue to check the code of null-transform.c, set a breakpoint at the
function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at
the breakpoint TSIOBufferBlockReadStart(), I print the return string of
TSIOBufferBlockReadStart(), there is no chunk data length at the head of
output string, which implies the api TSIOBufferBlockReadStart() has bug！
Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330,
avail=0xb6c8e288) at InkIOCoreAPI.cc:659
659 {
(gdb) s
660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
(gdb) n
667 p = blk-start();
(gdb)
668 if (avail)
(gdb) p p
$3 = 0xb1312000 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0
Transitional//EN\
\http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead\r\nmeta
http-equiv=\Conten...
(gdb)
--
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-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-937:
Assignee: Brian Geffon
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 3.1.2
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
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-1054) TSFetchUrl takes an address but does the DNS lookup anyway
[
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1054:
-
Assignee: James Peach
TSFetchUrl takes an address but does the DNS lookup anyway
--
Key: TS-1054
URL: https://issues.apache.org/jira/browse/TS-1054
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.2
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.1.2
TSFetchUrl() takes an IP address as one of its arguments, so the API client
has to resolve the hostname portion of any URL it wants to fetch. However
once you get into the HTTP state machine, the host gets resolved again. One
of these DNS queries is redundant for performance reasons. Additionally, the
plugin might have some special knowledge about which IP address to use that
the DNS resolver doesn't, in which case the result would be wrong.
[Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request
(90 of 90 bytes):
GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
accept: */*
[Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM
initialized for request with headers
--
GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
accept: */*
--
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect]
calling httpconnect write
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created
PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq)
HttpAccept:mainEvent] accepted connection
[Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session
born, netvc 0x102872e10
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using
accept inactivity timeout [120 seconds]
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting
transaction 1 using sm [0]
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
do_io_read for 0 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
do_io_read for -1 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
do_io_read for -1 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
do_io_write for 90 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive:
Received event 1
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; act_on 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
closed? 0 shutdown? 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active:
Received event 1
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_read_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_read_side; act_on 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
closed? 0 shutdown? 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side; act_on 90
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side; added 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[fetch_handler] calling fetch_plugin
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_write] calling process write
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; act_on 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; added 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
[HttpSM::main_handler, VC_EVENT_READ_READY]
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
[HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] done parsing
client request header
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
reenable Read
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START
HttpTransact::ModifyRequest
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans)
[ink_cluster_time] local: 1323923789, highest_delta: 0, cluster: 1323923789
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) END
[jira] [Updated] (TS-1048) Add TS API to enable plugins to use traffic server configuration infrastructure
[ https://issues.apache.org/jira/browse/TS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1048: -- Issue Type: New Feature (was: Improvement) Add TS API to enable plugins to use traffic server configuration infrastructure Key: TS-1048 URL: https://issues.apache.org/jira/browse/TS-1048 Project: Traffic Server Issue Type: New Feature Components: Configuration, TS API Environment: Centos 6 Reporter: bianca cooper Assignee: Leif Hedstrom Priority: Minor Labels: api-addition, configuration Fix For: 3.1.2 Attachments: TS-1048.diff, diff.txt Original Estimate: 72h Remaining Estimate: 72h Export RecRegisterConfigInt and RecRegisterConfigString to enable adding a configuration record to the records hashtable. Once plugin new configuration records should be added, the addition will be done by calling the API in the plugin code. No need to add the record to RecordsConfig static array. No need to recompile the ATS each time. -- 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-1007) SSN Close called before TXN Close
[ https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1007: -- Fix Version/s: (was: 3.1.2) 3.1.3 Looking for someone who wish to work on this (if so, just take it / assign it). Moving out unassigned bugs with no patches etc. to 3.1.3 for now. SSN Close called before TXN Close - Key: TS-1007 URL: https://issues.apache.org/jira/browse/TS-1007 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Nick Kew Priority: Critical Fix For: 3.1.3 Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the SSN_CLOSE_HOOK is called first of the two. This messes up normal cleanups! Details: Register a SSN_START event globally In the SSN START, add a TXN_START and a SSN_CLOSE In the TXN START, add a TXN_CLOSE Stepping through, I see the order of events actually called, for the simple case of a one-off HTTP request with no keepalive: SSN_START TXN_START SSN_END TXN_END Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the TXN! -- 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-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1045: -- Issue Type: New Feature (was: Improvement) PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: New Feature 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] [Commented] (TS-1070) replace and deprecate TSFetchURL()
[
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182335#comment-13182335
]
James Peach commented on TS-1070:
-
I'll take it.
replace and deprecate TSFetchURL()
--
Key: TS-1070
URL: https://issues.apache.org/jira/browse/TS-1070
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.1.2
TSFetchURL() has a number of shortcomings:
1. it's not cancellable
2. the event delivery is bizarre
3. it doesn't play nicely with the TSHttpHdr*() API.
I propose the following API changes:
typedef enum
{
...
TS_EVENT_FETCH_SUCCESS,
TS_EVENT_FETCH_FAILURE
} TSEvent;
TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *,
TSFetchWakeUpOptions);
TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and
MIME headers. If the HTTP method in the HTTP header is not GET, and a error
will be reported.
The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS
or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will
be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet().
For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error
code. Hopefully there is some existing precedent to follow.
TSFetchResource() should be cancellable via the TSAction return value.
I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we
eliminate this, I'd argue for a uint64_t flags parameter.
--
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-1070) replace and deprecate TSFetchURL()
[
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-1070:
---
Assignee: James Peach
replace and deprecate TSFetchURL()
--
Key: TS-1070
URL: https://issues.apache.org/jira/browse/TS-1070
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.1.2
TSFetchURL() has a number of shortcomings:
1. it's not cancellable
2. the event delivery is bizarre
3. it doesn't play nicely with the TSHttpHdr*() API.
I propose the following API changes:
typedef enum
{
...
TS_EVENT_FETCH_SUCCESS,
TS_EVENT_FETCH_FAILURE
} TSEvent;
TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *,
TSFetchWakeUpOptions);
TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and
MIME headers. If the HTTP method in the HTTP header is not GET, and a error
will be reported.
The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS
or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will
be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet().
For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error
code. Hopefully there is some existing precedent to follow.
TSFetchResource() should be cancellable via the TSAction return value.
I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we
eliminate this, I'd argue for a uint64_t flags parameter.
--
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=13182343#comment-13182343 ] James Peach commented on TS-1045: - Let's WONTFIX this one. The TSFetchUrl API is a bit weird but you can get the headers when you use right wakeup events, or have an unmodified ATS tree. PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: New Feature 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
