[jira] [Updated] (TS-3655) regression test segfault
[ https://issues.apache.org/jira/browse/TS-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-3655: --- Fix Version/s: 6.0.0 > regression test segfault > > > Key: TS-3655 > URL: https://issues.apache.org/jira/browse/TS-3655 > Project: Traffic Server > Issue Type: Bug >Reporter: weijin > Fix For: 6.0.0 > > > the regression test SDK_API_TSPortDescriptor forget to close the net_vc of > server side when free the caller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3655) regression test segfault
[
https://issues.apache.org/jira/browse/TS-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568710#comment-14568710
]
weijin commented on TS-3655:
{code}
(gdb) bt
#0 0x755415d7 in raise () from /lib64/libc.so.6
#1 0x75542cc8 in abort () from /lib64/libc.so.6
#2 0x77bc32a8 in ink_die_die_die () at ink_error.cc:43
#3 ink_fatal_va (fmt=0x77bcee67 "%s:%d: failed assert `%s`",
ap=ap@entry=0x73160b38) at ink_error.cc:65
#4 0x77bc333c in ink_fatal
(message_format=message_format@entry=0x77bcee67 "%s:%d: failed assert
`%s`") at ink_error.cc:73
#5 0x77bc1805 in _ink_assert (expression=,
file=, line=) at ink_assert.cc:37
#6 0x004bf1d3 in INKContInternal::handle_event (this=0x7fffd01c2860,
event=, edata=) at InkAPI.cc:994
#7 0x006c1368 in handleEvent (data=0x7fffd02056e8, event=105,
this=0x7fffd01c2860) at ../../iocore/eventsystem/I_Continuation.h:145
#8 read_signal_and_update (vc=0x7fffd02055d0, event=105) at
UnixNetVConnection.cc:139
#9 UnixNetVConnection::mainEvent (this=0x7fffd02055d0, event=,
e=) at UnixNetVConnection.cc:1110
#10 0x006b8e52 in handleEvent (data=0x1037b70, event=1,
this=0x7fffd02055d0) at ../../iocore/eventsystem/I_Continuation.h:145
#11 InactivityCop::check_inactivity (this=0xff7920, event=,
e=0x1037b70) at UnixNet.cc:109
#12 0x006e4de0 in handleEvent (data=0x1037b70, event=2, this=) at I_Continuation.h:145
#13 EThread::process_event (this=0x73566010, e=0x1037b70, calling_code=2)
at UnixEThread.cc:128
#14 0x006e5a01 in EThread::execute (this=0x73566010) at
UnixEThread.cc:207
#15 0x006e48ba in spawn_thread_internal (a=0xff4320) at Thread.cc:85
#16 0x762f7df5 in start_thread () from /lib64/libpthread.so.0
#17 0x756021ad in clone () from /lib64/libc.so.6
(gdb) f 6
#6 0x004bf1d3 in INKContInternal::handle_event (this=0x7fffd01c2860,
event=, edata=) at InkAPI.cc:994
994 ink_release_assert(!"Plugin tries to use a continuation which is
deleted");
(gdb) p *this
$1 = { = { = { =
{ = {_vptr.force_VFPT_to_top = 0x7fffd01c28c0},
handler = (int (Continuation::*)(Continuation * const, int, void *))
0x4bf110 , mutex = {m_ptr = 0x0},
link = {> = {next = 0x0}, prev = 0x0}}, lerrno =
0}, }, mdata = 0x7fffd01a3740, m_event_func = 0x5081d0
, m_event_count = 0, m_closed
= 1, m_deletable = 1, m_deleted = 1,
m_free_magic = INKCONT_INTERN_MAGIC_DEAD}
(gdb) la src
(gdb)
{code}
> regression test segfault
>
>
> Key: TS-3655
> URL: https://issues.apache.org/jira/browse/TS-3655
> Project: Traffic Server
> Issue Type: Bug
>Reporter: weijin
>
> the regression test SDK_API_TSPortDescriptor forget to close the net_vc of
> server side when free the caller.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3655) regression test segfault
weijin created TS-3655: -- Summary: regression test segfault Key: TS-3655 URL: https://issues.apache.org/jira/browse/TS-3655 Project: Traffic Server Issue Type: Bug Reporter: weijin the regression test SDK_API_TSPortDescriptor forget to close the net_vc of server side when free the caller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3628) unable to use very large disk ( > 16T)
[ https://issues.apache.org/jira/browse/TS-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-3628: --- Fix Version/s: 6.0.0 > unable to use very large disk ( > 16T) > -- > > Key: TS-3628 > URL: https://issues.apache.org/jira/browse/TS-3628 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 5.3.0 >Reporter: weijin >Assignee: weijin > Fix For: 6.0.0 > > > when disk or file (> 16T), the blocks should larger than 2^31. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3628) unable to use very large disk ( > 16T)
[ https://issues.apache.org/jira/browse/TS-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-3628: --- Affects Version/s: 5.3.0 > unable to use very large disk ( > 16T) > -- > > Key: TS-3628 > URL: https://issues.apache.org/jira/browse/TS-3628 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 5.3.0 >Reporter: weijin >Assignee: weijin > > when disk or file (> 16T), the blocks should larger than 2^31. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3628) unable to use very large disk ( > 16T)
[ https://issues.apache.org/jira/browse/TS-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin reassigned TS-3628: -- Assignee: weijin > unable to use very large disk ( > 16T) > -- > > Key: TS-3628 > URL: https://issues.apache.org/jira/browse/TS-3628 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: weijin >Assignee: weijin > > when disk or file (> 16T), the blocks should larger than 2^31. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3628) unable to use very large disk ( > 16T)
weijin created TS-3628: -- Summary: unable to use very large disk ( > 16T) Key: TS-3628 URL: https://issues.apache.org/jira/browse/TS-3628 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: weijin when disk or file (> 16T), the blocks should larger than 2^31. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3315) Assert after try lock
[
https://issues.apache.org/jira/browse/TS-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14288662#comment-14288662
]
weijin commented on TS-3315:
the try lock of cont->mutex should never fail. If fail, which means the caller
may have flaws or bugs.
> Assert after try lock
> -
>
> Key: TS-3315
> URL: https://issues.apache.org/jira/browse/TS-3315
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Phil Sorber
>
> In iocore/cache/Cache.cc there is the following:
> {code}
> CACHE_TRY_LOCK(lock, cont->mutex, this_ethread());
> ink_assert(lock.is_locked());
> {code}
> Does it really make sense to try and assert when a try can fail?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3044) linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110206#comment-14110206 ] weijin commented on TS-3044: Nice work, John. And I can`t wait to test it. :) > linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: weijin > Fix For: 5.2.0 > > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2912: --- Attachment: ts-2912.try1.diff @William Bardwell, [~zwoop] I wrote a patch to solve the bug, please review it if you have time. > HEAD transaction on stale entry deletes cache entry > --- > > Key: TS-2912 > URL: https://issues.apache.org/jira/browse/TS-2912 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell >Assignee: weijin > Fix For: 5.1.0 > > Attachments: ts-2912.try1.diff > > > On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 > comes back > HttpTransact::handle_cache_operation_on_forward_server_response(State* s) > deletes the cache entry, it seems like it should just ignore it (or check > ETag/Last-Modified and maybe delete if those don't match, but not > unconditionally.) > I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code > looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin reassigned TS-2912: -- Assignee: weijin > HEAD transaction on stale entry deletes cache entry > --- > > Key: TS-2912 > URL: https://issues.apache.org/jira/browse/TS-2912 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell >Assignee: weijin > Fix For: 5.1.0 > > > On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 > comes back > HttpTransact::handle_cache_operation_on_forward_server_response(State* s) > deletes the cache entry, it seems like it should just ignore it (or check > ETag/Last-Modified and maybe delete if those don't match, but not > unconditionally.) > I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code > looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2494: --- Priority: Critical (was: Major) > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.5, 4.0.2, 4.1.2 >Reporter: weijin >Assignee: weijin >Priority: Critical > Fix For: 4.2.0 > > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870576#comment-13870576 ] weijin commented on TS-2494: traffic_line -s proxy.config.http.negative_caching_enabled -v 1 traffic_line -s proxy.config.http.negative_caching_lifetime -v 1 and the stale cached copy is not a 200 OK document but a 404 (not found) document. > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.5, 4.0.2, 4.1.2 >Reporter: weijin >Assignee: weijin >Priority: Critical > Fix For: 4.2.0 > > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2494: --- Affects Version/s: 3.2.5 4.0.2 4.1.2 > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.5, 4.0.2, 4.1.2 >Reporter: weijin >Assignee: weijin >Priority: Critical > Fix For: 4.2.0 > > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2494: --- Fix Version/s: 4.2.0 > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.2.5, 4.0.2, 4.1.2 >Reporter: weijin >Assignee: weijin >Priority: Critical > Fix For: 4.2.0 > > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[
https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870564#comment-13870564
]
weijin commented on TS-2494:
{code}
#0 0x003f4cc328a5 in raise () from /lib64/libc.so.6
#1 0x003f4cc34085 in abort () from /lib64/libc.so.6
#2 0x77de269c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77de2769 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`",
ap=0x756bd410) at ink_error.cc:65
#4 0x77de2832 in ink_fatal (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x77de1494 in _ink_assert (expression=0x6f25fb "valid()",
file=0x6f2603 "./hdrs/HTTP.h", line=986) at ink_assert.cc:37
#6 0x00504fe5 in HTTPHdr::type_get (this=0x710d4950) at
./hdrs/HTTP.h:986
#7 0x0059e681 in HttpTransact::handle_response_keep_alive_headers
(s=0x710d4270, ver=..., heads=0x710d4950)
at HttpTransact.cc:6732
#8 0x005a2b74 in HttpTransact::build_response (s=0x710d4270,
base_response=0x7fffe004d8a0,
outgoing_response=0x710d4950, outgoing_version=...,
status_code=HTTP_STATUS_OK, reason_phrase=0x733b69 "OK")
at HttpTransact.cc:7743
#9 0x005952f6 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x710d4270) at HttpTransact.cc:4156
#10 0x00593e62 in HttpTransact::handle_forward_server_connection_open
(s=0x710d4270) at HttpTransact.cc:3815
#11 0x00592532 in HttpTransact::handle_response_from_server
(s=0x710d4270) at HttpTransact.cc:3492
#12 0x00590f2e in HttpTransact::HandleResponse (s=0x710d4270) at
HttpTransact.cc:3183
#13 0x00578ea1 in HttpSM::call_transact_and_set_next_state
(this=0x710d4200, f=0) at HttpSM.cc:6764
#14 0x00566564 in HttpSM::handle_api_return (this=0x710d4200) at
HttpSM.cc:1555
#15 0x0057ec39 in HttpSM::do_api_callout (this=0x710d4200) at
HttpSM.cc:502
#16 0x005675ff in HttpSM::state_read_server_response_header
(this=0x710d4200, event=100, data=0x7fffe8015ed0)
at HttpSM.cc:1892
#17 0x00569be6 in HttpSM::main_handler (this=0x710d4200, event=100,
data=0x7fffe8015ed0) at HttpSM.cc:2522
#18 0x004e7aa4 in Continuation::handleEvent (this=0x710d4200,
event=100, data=0x7fffe8015ed0)
at ../iocore/eventsystem/I_Continuation.h:146
#19 0x006c7683 in read_signal_and_update (event=100, vc=0x7fffe8015dc0)
at UnixNetVConnection.cc:138
#20 0x006c7fd4 in read_from_net (nh=0x760d3bf0, vc=0x7fffe8015dc0,
thread=0x760d0010) at UnixNetVConnection.cc:320
#21 0x006c9ea9 in UnixNetVConnection::net_read_io (this=0x7fffe8015dc0,
nh=0x760d3bf0, lthread=0x760d0010)
at UnixNetVConnection.cc:835
#22 0x006c1724 in NetHandler::mainNetEvent (this=0x760d3bf0,
event=5, e=0x10d3930) at UnixNet.cc:384
#23 0x004e7aa4 in Continuation::handleEvent (this=0x760d3bf0,
event=5, data=0x10d3930)
at ../iocore/eventsystem/I_Continuation.h:146
#24 0x006e9c0e in EThread::process_event (this=0x760d0010,
e=0x10d3930, calling_code=5) at UnixEThread.cc:145
#25 0x006ea1f0 in EThread::execute (this=0x760d0010) at
UnixEThread.cc:269
#26 0x006e913b in spawn_thread_internal (a=0x1062320) at Thread.cc:88
#27 0x0030e4207851 in start_thread () from /lib64/libpthread.so.0
#28 0x003f4cce767d in clone () from /lib64/libc.so.6
{code}
> ts crash if negative_revalidating_enabled when the os is down
> -
>
> Key: TS-2494
> URL: https://issues.apache.org/jira/browse/TS-2494
> Project: Traffic Server
> Issue Type: Bug
>Reporter: weijin
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870567#comment-13870567 ] weijin commented on TS-2494: traffic_line -s proxy.config.http.negative_revalidating_enabled -v 1 traffic_line -s proxy.config.http.negative_revalidating_lifetime -v 60 if the cached copy is stale and the os is down, the crash occurs. > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Reporter: weijin > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2494: --- Attachment: TS-2494.diff > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Reporter: weijin >Assignee: weijin > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
weijin created TS-2494: -- Summary: ts crash if negative_revalidating_enabled when the os is down Key: TS-2494 URL: https://issues.apache.org/jira/browse/TS-2494 Project: Traffic Server Issue Type: Bug Reporter: weijin -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin reassigned TS-2494: -- Assignee: weijin > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Reporter: weijin >Assignee: weijin > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Work started] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2494 started by weijin. > ts crash if negative_revalidating_enabled when the os is down > - > > Key: TS-2494 > URL: https://issues.apache.org/jira/browse/TS-2494 > Project: Traffic Server > Issue Type: Bug >Reporter: weijin >Assignee: weijin > Attachments: TS-2494.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-656) reimplement Connection Collapsing in a smooth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870438#comment-13870438 ] weijin commented on TS-656: --- I`ll focus on this project in the next few weeks, maybe months. > reimplement Connection Collapsing in a smooth way > - > > Key: TS-656 > URL: https://issues.apache.org/jira/browse/TS-656 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 2.1.6 > Environment: per discussed in IRC, we'd like to clean the current CC > codes from trunk. >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 6.0.0 > > > we should figure out how to implement the Connection Collapsing that not so > ugly. target for V3.1 or so. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870429#comment-13870429
]
weijin commented on TS-2205:
It maybe related to TS-2027, so we can close this now, reopen it if arise
again.
> AIO caused system hang
> --
>
> Key: TS-2205
> URL: https://issues.apache.org/jira/browse/TS-2205
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.0.1
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Critical
> Fix For: 4.2.0
>
>
> the system may hang with AIO thread CPU usage rising:
> {code}
> top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
> Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
> Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
> Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
> 3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
> 3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
> 4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
>13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
>37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
>45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
> 32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
> 32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
>25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
>65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
> 32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
> 32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
> 32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
> 32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
> 32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
> 32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
> 32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
> 32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
> 32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
> 32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
> 32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
> 32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
> 32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
> 32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin closed TS-2205.
--
Resolution: Fixed
> AIO caused system hang
> --
>
> Key: TS-2205
> URL: https://issues.apache.org/jira/browse/TS-2205
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.0.1
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Critical
> Fix For: 4.2.0
>
>
> the system may hang with AIO thread CPU usage rising:
> {code}
> top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
> Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
> Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
> Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
> 3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
> 3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
> 4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
>13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
>37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
>45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
> 32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
> 32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
>25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
>65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
> 32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
> 32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
> 32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
> 32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
> 32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
> 32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
> 32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
> 32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
> 32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
> 32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
> 32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
> 32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
> 32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
> 32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-1821) AIO tests don't build with native AIO
[ https://issues.apache.org/jira/browse/TS-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-1821. Resolution: Fixed > AIO tests don't build with native AIO > - > > Key: TS-1821 > URL: https://issues.apache.org/jira/browse/TS-1821 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: weijin > Fix For: 5.0.0 > > Attachments: ts-1821.wj.diff > > > /opt/src/trafficserver.git/configure --prefix=/opt/ats > --enable-linux-native-aio && make -j 4 && make check > test_AIO-test_AIO.o: In function `main': > /opt/src/trafficserver.git/iocore/aio/test_AIO.cc:498: undefined reference to > `cache_config_threads_per_disk' > collect2: error: ld returned 1 exit status -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
[ https://issues.apache.org/jira/browse/TS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-2412. Resolution: Fixed > Using linux native-AIO, restarting ATS causes complete cache data loss > -- > > Key: TS-2412 > URL: https://issues.apache.org/jira/browse/TS-2412 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache >Reporter: weijin >Assignee: weijin > Fix For: 4.2.0 > > Attachments: ts-2412.wj.diff > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869300#comment-13869300
]
weijin commented on TS-2138:
I provide a patch on TS-2412 for this problem. please test it.
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-2450) assert triggered in ssl startup when --enable-debug
[ https://issues.apache.org/jira/browse/TS-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-2450. Resolution: Fixed > assert triggered in ssl startup when --enable-debug > --- > > Key: TS-2450 > URL: https://issues.apache.org/jira/browse/TS-2450 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: weijin > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (TS-2450) assert triggered in ssl startup when --enable-debug
[
https://issues.apache.org/jira/browse/TS-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855687#comment-13855687
]
weijin edited comment on TS-2450 at 12/23/13 3:44 PM:
--
{code}
(gdb) bt
#0 0x003f4cc328a5 in raise () from /lib64/libc.so.6
#1 0x003f4cc34085 in abort () from /lib64/libc.so.6
#2 0x77de268c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77de2759 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`",
ap=0x7fffd430) at ink_error.cc:65
#4 0x77de2822 in ink_fatal (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x77de1484 in _ink_assert (
expression=0x7623c8 "ASN1_STRING_type(s) == V_ASN1_IA5STRING ||
ASN1_STRING_type(s) == V_ASN1_UTF8STRING || ASN1_STRING_type(s) ==
V_ASN1_PRINTABLESTRING", file=0x761ef7 "SSLUtils.cc", line=603) at
ink_assert.cc:37
#6 0x006bd943 in asn1_strdup (s=0x1202130) at SSLUtils.cc:603
#7 0x006bda4c in ssl_index_certificate (lookup=0x11f43e0,
ctx=0x11fdc60,
certfile=0x11fd490 "/etc/trafficserver/alipayobjects.com_2013.cer") at
SSLUtils.cc:631
#8 0x006be088 in ssl_store_ssl_context (params=0x11f4170,
lookup=0x11f43e0, addr=..., cert=..., ca=..., key=...,
session_ticket_enabled=-1, ticket_key_filename=...) at SSLUtils.cc:720
#9 0x006be667 in SSLParseCertificateConfiguration (params=0x11f4170,
lookup=0x11f43e0) at SSLUtils.cc:835
#10 0x006d45b8 in SSLCertificateConfig::reconfigure () at
SSLConfig.cc:287
#11 0x006d4544 in SSLCertificateConfig::startup () at SSLConfig.cc:278
#12 0x006b7860 in SSLNetProcessor::start (this=0xf9c8c0,
number_of_ssl_threads=12, stacksize=1048576)
at SSLNetProcessor.cc:54
#13 0x0050f4e0 in main (argv=0x7fffe1b8) at Main.cc:1507
(gdb) p *s
$2 = {length = 19, type = 20, data = 0x12021a0 "*.alipayobjects.com", flags =
64}
{code}
was (Author: weijin):
{code}
(gdb) bt
#0 0x003f4cc328a5 in raise () from /lib64/libc.so.6
#1 0x003f4cc34085 in abort () from /lib64/libc.so.6
#2 0x77de268c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77de2759 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`",
ap=0x7fffd430) at ink_error.cc:65
#4 0x77de2822 in ink_fatal (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x77de1484 in _ink_assert (
expression=0x7623c8 "ASN1_STRING_type(s) == V_ASN1_IA5STRING ||
ASN1_STRING_type(s) == V_ASN1_UTF8STRING || ASN1_STRING_type(s) ==
V_ASN1_PRINTABLESTRING", file=0x761ef7 "SSLUtils.cc", line=603) at
ink_assert.cc:37
#6 0x006bd943 in asn1_strdup (s=0x1202130) at SSLUtils.cc:603
#7 0x006bda4c in ssl_index_certificate (lookup=0x11f43e0,
ctx=0x11fdc60,
certfile=0x11fd490 "/etc/trafficserver/alipayobjects.com_2013.cer") at
SSLUtils.cc:631
#8 0x006be088 in ssl_store_ssl_context (params=0x11f4170,
lookup=0x11f43e0, addr=..., cert=..., ca=..., key=...,
session_ticket_enabled=-1, ticket_key_filename=...) at SSLUtils.cc:720
#9 0x006be667 in SSLParseCertificateConfiguration (params=0x11f4170,
lookup=0x11f43e0) at SSLUtils.cc:835
#10 0x006d45b8 in SSLCertificateConfig::reconfigure () at
SSLConfig.cc:287
#11 0x006d4544 in SSLCertificateConfig::startup () at SSLConfig.cc:278
#12 0x006b7860 in SSLNetProcessor::start (this=0xf9c8c0,
number_of_ssl_threads=12, stacksize=1048576)
at SSLNetProcessor.cc:54
#13 0x0050f4e0 in main (argv=0x7fffe1b8) at Main.cc:1507
(gdb) p *s
$2 = {length = 19, type = 20, data = 0x12021a0 "*.alipayobjects.com", flags =
64}
{/code}
> assert triggered in ssl startup when --enable-debug
> ---
>
> Key: TS-2450
> URL: https://issues.apache.org/jira/browse/TS-2450
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: weijin
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2450) assert triggered in ssl startup when --enable-debug
[
https://issues.apache.org/jira/browse/TS-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13855687#comment-13855687
]
weijin commented on TS-2450:
{code}
(gdb) bt
#0 0x003f4cc328a5 in raise () from /lib64/libc.so.6
#1 0x003f4cc34085 in abort () from /lib64/libc.so.6
#2 0x77de268c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77de2759 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`",
ap=0x7fffd430) at ink_error.cc:65
#4 0x77de2822 in ink_fatal (return_code=1,
message_format=0x77df0800 "%s:%d: failed assert `%s`") at ink_error.cc:73
#5 0x77de1484 in _ink_assert (
expression=0x7623c8 "ASN1_STRING_type(s) == V_ASN1_IA5STRING ||
ASN1_STRING_type(s) == V_ASN1_UTF8STRING || ASN1_STRING_type(s) ==
V_ASN1_PRINTABLESTRING", file=0x761ef7 "SSLUtils.cc", line=603) at
ink_assert.cc:37
#6 0x006bd943 in asn1_strdup (s=0x1202130) at SSLUtils.cc:603
#7 0x006bda4c in ssl_index_certificate (lookup=0x11f43e0,
ctx=0x11fdc60,
certfile=0x11fd490 "/etc/trafficserver/alipayobjects.com_2013.cer") at
SSLUtils.cc:631
#8 0x006be088 in ssl_store_ssl_context (params=0x11f4170,
lookup=0x11f43e0, addr=..., cert=..., ca=..., key=...,
session_ticket_enabled=-1, ticket_key_filename=...) at SSLUtils.cc:720
#9 0x006be667 in SSLParseCertificateConfiguration (params=0x11f4170,
lookup=0x11f43e0) at SSLUtils.cc:835
#10 0x006d45b8 in SSLCertificateConfig::reconfigure () at
SSLConfig.cc:287
#11 0x006d4544 in SSLCertificateConfig::startup () at SSLConfig.cc:278
#12 0x006b7860 in SSLNetProcessor::start (this=0xf9c8c0,
number_of_ssl_threads=12, stacksize=1048576)
at SSLNetProcessor.cc:54
#13 0x0050f4e0 in main (argv=0x7fffe1b8) at Main.cc:1507
(gdb) p *s
$2 = {length = 19, type = 20, data = 0x12021a0 "*.alipayobjects.com", flags =
64}
{/code}
> assert triggered in ssl startup when --enable-debug
> ---
>
> Key: TS-2450
> URL: https://issues.apache.org/jira/browse/TS-2450
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: weijin
>
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2450) assert triggered in ssl startup when --enable-debug
weijin created TS-2450: -- Summary: assert triggered in ssl startup when --enable-debug Key: TS-2450 URL: https://issues.apache.org/jira/browse/TS-2450 Project: Traffic Server Issue Type: Bug Components: Core Reporter: weijin -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (TS-899) ts crash
[ https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin closed TS-899. - Resolution: Unresolved > ts crash > > > Key: TS-899 > URL: https://issues.apache.org/jira/browse/TS-899 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP, MIME >Affects Versions: 3.0.1 > Environment: readhat5.5, ts-3.0.1, X86-64 >Reporter: weijin >Assignee: weijin > Labels: crash > Fix For: sometime > > > If a request url is forbidden then redirected to another url, TS crash. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (TS-899) ts crash
[ https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852459#comment-13852459 ] weijin commented on TS-899: --- [~zwoop] maybe it`s better to close it now. It seems difficult to reproduce now. > ts crash > > > Key: TS-899 > URL: https://issues.apache.org/jira/browse/TS-899 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP, MIME >Affects Versions: 3.0.1 > Environment: readhat5.5, ts-3.0.1, X86-64 >Reporter: weijin >Assignee: weijin > Labels: crash > Fix For: sometime > > > If a request url is forbidden then redirected to another url, TS crash. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (TS-2432) a race in disk_err_handler that may lead we can not rebuild the hash_table of cache
weijin created TS-2432: -- Summary: a race in disk_err_handler that may lead we can not rebuild the hash_table of cache Key: TS-2432 URL: https://issues.apache.org/jira/browse/TS-2432 Project: Traffic Server Issue Type: Bug Reporter: weijin -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
[ https://issues.apache.org/jira/browse/TS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837361#comment-13837361 ] weijin commented on TS-2412: @Soctt Harris The patch seems work in my system. could you please test it if you have time. thanks very much! > Using linux native-AIO, restarting ATS causes complete cache data loss > -- > > Key: TS-2412 > URL: https://issues.apache.org/jira/browse/TS-2412 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache >Reporter: weijin > Attachments: ts-2412.wj.diff > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
[ https://issues.apache.org/jira/browse/TS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2412: --- Attachment: ts-2412.wj.diff > Using linux native-AIO, restarting ATS causes complete cache data loss > -- > > Key: TS-2412 > URL: https://issues.apache.org/jira/browse/TS-2412 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache >Reporter: weijin > Attachments: ts-2412.wj.diff > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
weijin created TS-2412: -- Summary: Using linux native-AIO, restarting ATS causes complete cache data loss Key: TS-2412 URL: https://issues.apache.org/jira/browse/TS-2412 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: weijin -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2412) Using linux native-AIO, restarting ATS causes complete cache data loss
[ https://issues.apache.org/jira/browse/TS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2412: --- Issue Type: Sub-task (was: Bug) Parent: TS-2138 > Using linux native-AIO, restarting ATS causes complete cache data loss > -- > > Key: TS-2412 > URL: https://issues.apache.org/jira/browse/TS-2412 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache >Reporter: weijin > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837355#comment-13837355
]
weijin commented on TS-2138:
@Soctt Harris
the last commit still not solve the problem completely and the master still
clear cache when aio enabled.
I`ll open a ticket for this and write a patch for it.
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.1.1
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2374) http_sm hung when all consumers aborted but the producer still alive
[ https://issues.apache.org/jira/browse/TS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2374: --- Backport to Version: 4.0.2 Fix Version/s: 4.2.0 Assignee: weijin > http_sm hung when all consumers aborted but the producer still alive > > > Key: TS-2374 > URL: https://issues.apache.org/jira/browse/TS-2374 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Fix For: 4.2.0 > > > HttpSM will kill_this when the tunnel is not alive (none of consumer alive, > nor the producer). But when the cache_vc (for write) is the only consumer of > the server_session, and the consumer is aborted because of write failed, the > httpsm hung. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2374) http_sm hung when all consumers aborted but the producer still alive
weijin created TS-2374: -- Summary: http_sm hung when all consumers aborted but the producer still alive Key: TS-2374 URL: https://issues.apache.org/jira/browse/TS-2374 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin HttpSM will kill_this when the tunnel is not alive (none of consumer alive, nor the producer). But when the cache_vc (for write) is the only consumer of the server_session, and the consumer is aborted because of write failed, the httpsm hung. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TS-2246) when the CacheVC callbacked with openWriteCloseDataDone, should canncel the trigger.
[ https://issues.apache.org/jira/browse/TS-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-2246. Resolution: Fixed Assignee: weijin > when the CacheVC callbacked with openWriteCloseDataDone, should canncel the > trigger. > > > Key: TS-2246 > URL: https://issues.apache.org/jira/browse/TS-2246 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: weijin >Assignee: weijin > Fix For: 4.1.1 > > > when do_write_lock_call not hold the Vol`s lock, CacheVC rescheduled. we > canncel the trigger in openWriteCloseDataDone to make it more safe. > Especially when we Constrain the size of doc not exceed 1M. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2139) Twice purge to refresh object form cache when enable-interim-cache
[ https://issues.apache.org/jira/browse/TS-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802549#comment-13802549 ] weijin commented on TS-2139: [~bettydreamit] we can just remove the dir of inerim_cache for cache remove > Twice purge to refresh object form cache when enable-interim-cache > -- > > Key: TS-2139 > URL: https://issues.apache.org/jira/browse/TS-2139 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: bettydramit >Assignee: portl4t > Fix For: 5.0.0 > > Attachments: 0001-fix-purge-twice.patch > > > Centos x86_64 gitmaster and > http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2 > when enable enable-interim-cache > It muse use twice purge to refresh object form cache > my records.config > LOCAL proxy.config.cache.interim.storage STRING /dev/vdb > Test example: > [root@localhost trafficserver]# wget -SO /dev/null -e http_proxy=127.0.0.1 > http://www.test.com/ben.bf > --2013-08-17 14:45:23-- http://www.test.com/ben.bf > Connecting to 127.0.0.1:80... connected. > Proxy request sent, awaiting response... > HTTP/1.0 200 OK > Date: Sat, 17 Aug 2013 06:38:13 GMT > Server: ATS/3.3.5-dev > Last-Modified: Mon, 08 Jul 2013 15:26:09 GMT > ETag: "41d26-103-4e101a9fc2c93" > Accept-Ranges: bytes > Content-Length: 259 > Content-Type: text/plain; charset=UTF-8 > Age: 430 > Length: 259 [text/plain] > Saving to: “/dev/null” > 100%[>] > 259 --.-K/s in 0s > 2013-08-17 14:45:23 (38.5 MB/s) - “/dev/null” saved [259/259] > [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v > http://www.test.com/ben.bf > * About to connect() to proxy 127.0.0.1 port 80 (#0) > * Trying 127.0.0.1... connected > * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) > > purge http://www.test.com/ben.bf HTTP/1.1 > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: www.test.com > > Accept: */* > > Proxy-Connection: Keep-Alive > > > < HTTP/1.1 200 OK > < Date: Sat, 17 Aug 2013 06:45:28 GMT > < Proxy-Connection: keep-alive > < Server: ATS/3.3.5-dev > < Content-Length: 0 > < > * Connection #0 to host 127.0.0.1 left intact > * Closing connection #0 > [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v > http://www.test.com/ben.bf > * About to connect() to proxy 127.0.0.1 port 80 (#0) > * Trying 127.0.0.1... connected > * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) > > purge http://www.test.com/ben.bf HTTP/1.1 > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: www.test.com > > Accept: */* > > Proxy-Connection: Keep-Alive > > > < HTTP/1.1 200 OK > < Date: Sat, 17 Aug 2013 06:45:29 GMT > < Proxy-Connection: keep-alive > < Server: ATS/3.3.5-dev > < Content-Length: 0 > < > * Connection #0 to host 127.0.0.1 left intact > * Closing connection #0 > [root@localhost trafficserver]# curl -X purge -x 127.0.0.1:80 -v > http://www.test.com/ben.bf > * About to connect() to proxy 127.0.0.1 port 80 (#0) > * Trying 127.0.0.1... connected > * Connected to 127.0.0.1 (127.0.0.1) port 80 (#0) > > purge http://www.test.com/ben.bf HTTP/1.1 > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 > > NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Host: www.test.com > > Accept: */* > > Proxy-Connection: Keep-Alive > > > < HTTP/1.1 404 Not Found > < Date: Sat, 17 Aug 2013 06:45:33 GMT > < Proxy-Connection: keep-alive > < Server: ATS/3.3.5-dev > < Content-Length: 0 > < > * Connection #0 to host 127.0.0.1 left intact > * Closing connection #0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin updated TS-2138:
---
Attachment: TS-2138.wj.diff
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: sometime
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (TS-2197) http_sm may not perceive client_vc`s aborted if it is not a new connection
[ https://issues.apache.org/jira/browse/TS-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-2197. Resolution: Fixed > http_sm may not perceive client_vc`s aborted if it is not a new connection > -- > > Key: TS-2197 > URL: https://issues.apache.org/jira/browse/TS-2197 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin > Fix For: 4.1.0 > > Attachments: TS-2197.wj.diff > > > for a keepalive connection, the second request maybe already in the > ua_buffer, the current code disabled the client_vc`s read when parse the > http_hdr in such case, which means we can not notified the client_vc is > aborted as soon as possible. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2253: --- Attachment: TS-2253.wj.diff I wrote a patch base one the previous one. 1. for the inactive_timeout_at < now, just return at the beginning. 2. replace MUTEX_TAKE_TRY_LOCK with MUTEX_TRY_LOCK to make the code clean. 3. remove some codes process_timeout because the process_timeout is under the lock of vio.mutex already. > PluginVC::process_close Segmentation fault > --- > > Key: TS-2253 > URL: https://issues.apache.org/jira/browse/TS-2253 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: bettydramit >Assignee: weijin > Fix For: 4.1.0 > > Attachments: 4.0.1.patch, TS-2253.wj.diff > > > Env: centos 6 x86_64 ats 4.0.1 > [E. Mgmt] log ==> [TrafficManager] using root directory '/usr' > [TrafficServer] using root directory '/usr' > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] > [0x2b7b3e825ac0] > gdb info > Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from > /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. > done. > Loaded symbols for /lib64/libnss_dns-2.12.so > Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. > Program terminated with signal 11, Segmentation fault. > #0 0x2ac40034ed80 in ?? () > Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 > (gdb) where > #0 0x2ac40034ed80 in ?? () > #1 0x004d1ef2 in PluginVC::process_close() () > #2 0x004d2938 in PluginVC::main_handler(int, void*) () > #3 0x006a372f in EThread::process_event(Event*, int) () > #4 0x006a42ab in EThread::execute() () > #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790213#comment-13790213 ] weijin commented on TS-2253: It seems this bug come from Ts-1427, which set inactive_event as period type (like inactive_cop), but when the lock miss, it changed to normal type again. When the inactive_event (with normal type) triggered but not handle by process_timeout ( inactive_timeout_at > now), the inactive_event is freed but PluginVC still hold it. > PluginVC::process_close Segmentation fault > --- > > Key: TS-2253 > URL: https://issues.apache.org/jira/browse/TS-2253 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: bettydramit >Assignee: weijin > Fix For: 4.1.0 > > Attachments: 4.0.1.patch > > > Env: centos 6 x86_64 ats 4.0.1 > [E. Mgmt] log ==> [TrafficManager] using root directory '/usr' > [TrafficServer] using root directory '/usr' > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] > [0x2b7b3e825ac0] > gdb info > Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from > /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. > done. > Loaded symbols for /lib64/libnss_dns-2.12.so > Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. > Program terminated with signal 11, Segmentation fault. > #0 0x2ac40034ed80 in ?? () > Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 > (gdb) where > #0 0x2ac40034ed80 in ?? () > #1 0x004d1ef2 in PluginVC::process_close() () > #2 0x004d2938 in PluginVC::main_handler(int, void*) () > #3 0x006a372f in EThread::process_event(Event*, int) () > #4 0x006a42ab in EThread::execute() () > #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin reassigned TS-2253: -- Assignee: weijin > PluginVC::process_close Segmentation fault > --- > > Key: TS-2253 > URL: https://issues.apache.org/jira/browse/TS-2253 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: bettydramit >Assignee: weijin > Fix For: 4.1.0 > > Attachments: 4.0.1.patch > > > Env: centos 6 x86_64 ats 4.0.1 > [E. Mgmt] log ==> [TrafficManager] using root directory '/usr' > [TrafficServer] using root directory '/usr' > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] > [0x2b7b3e825ac0] > gdb info > Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from > /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. > done. > Loaded symbols for /lib64/libnss_dns-2.12.so > Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. > Program terminated with signal 11, Segmentation fault. > #0 0x2ac40034ed80 in ?? () > Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 > (gdb) where > #0 0x2ac40034ed80 in ?? () > #1 0x004d1ef2 in PluginVC::process_close() () > #2 0x004d2938 in PluginVC::main_handler(int, void*) () > #3 0x006a372f in EThread::process_event(Event*, int) () > #4 0x006a42ab in EThread::execute() () > #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2246) when the CacheVC callbacked with openWriteCloseDataDone, should canncel the trigger.
weijin created TS-2246: -- Summary: when the CacheVC callbacked with openWriteCloseDataDone, should canncel the trigger. Key: TS-2246 URL: https://issues.apache.org/jira/browse/TS-2246 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: weijin when do_write_lock_call not hold the Vol`s lock, CacheVC rescheduled. we canncel the trigger in openWriteCloseDataDone to make it more safe. Especially when we Constrain the size of doc not exceed 1M. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2235) url_print should NOT output "?" for empty query string
[ https://issues.apache.org/jira/browse/TS-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770534#comment-13770534 ] weijin commented on TS-2235: @Leif from the code, the calculating of cache key is not based on url_print. > url_print should NOT output "?" for empty query string > --- > > Key: TS-2235 > URL: https://issues.apache.org/jira/browse/TS-2235 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Reporter: Yu Qing >Assignee: Yu Qing > Attachments: > 0001-TS-2235-url_print-should-NOT-output-for-empty-query-.patch > > > the same problem with parameter and fragment parts. > for example: a remap plugin removes the query part (set query to empty), but > the remaped url end with "?". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2191) when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2191: --- Backport to Version: 4.0.2 Assignee: weijin > when http_info enabled, the http_sm may be deleted but a event associated it > not cancelled. > > > Key: TS-2191 > URL: https://issues.apache.org/jira/browse/TS-2191 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2197) http_sm may not perceive client_vc`s aborted if it is not a new connection
[ https://issues.apache.org/jira/browse/TS-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2197: --- Attachment: TS-2197.wj.diff not call the state_read_client_request_header directly, or else the http_sm maybe deleted before the function return. > http_sm may not perceive client_vc`s aborted if it is not a new connection > -- > > Key: TS-2197 > URL: https://issues.apache.org/jira/browse/TS-2197 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin > Attachments: TS-2197.wj.diff > > > for a keepalive connection, the second request maybe already in the > ua_buffer, the current code disabled the client_vc`s read when parse the > http_hdr in such case, which means we can not notified the client_vc is > aborted as soon as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2197) http_sm may not perceive client_vc`s aborted if it is not a new connection
weijin created TS-2197: -- Summary: http_sm may not perceive client_vc`s aborted if it is not a new connection Key: TS-2197 URL: https://issues.apache.org/jira/browse/TS-2197 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin for a keepalive connection, the second request maybe already in the ua_buffer, the current code disabled the client_vc`s read when parse the http_hdr in such case, which means we can not notified the client_vc is aborted as soon as possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2192) sm_list may miss some http_sms if it is lock contention
weijin created TS-2192: -- Summary: sm_list may miss some http_sms if it is lock contention Key: TS-2192 URL: https://issues.apache.org/jira/browse/TS-2192 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: weijin it is a sub task of TS-2191. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2191) when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2191: --- Attachment: TS-2191.wj.diff > when http_info enabled, the http_sm may be deleted but a event associated it > not cancelled. > > > Key: TS-2191 > URL: https://issues.apache.org/jira/browse/TS-2191 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2191) when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
weijin created TS-2191: -- Summary: when http_info enabled, the http_sm may be deleted but a event associated it not cancelled. Key: TS-2191 URL: https://issues.apache.org/jira/browse/TS-2191 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin if the http_info enabled, when the sm_list`s lock not acquired but the client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2099) typo error in when set active_timeout of netvc
[ https://issues.apache.org/jira/browse/TS-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2099: --- Attachment: TS-2099.diff > typo error in when set active_timeout of netvc > -- > > Key: TS-2099 > URL: https://issues.apache.org/jira/browse/TS-2099 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: weijin > Attachments: TS-2099.diff > > > TS-1501 has a typo error when set_active_timeout of netvc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2099) typo error in when set active_timeout of netvc
weijin created TS-2099: -- Summary: typo error in when set active_timeout of netvc Key: TS-2099 URL: https://issues.apache.org/jira/browse/TS-2099 Project: Traffic Server Issue Type: Bug Components: Core Reporter: weijin TS-1501 has a typo error when set_active_timeout of netvc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1223) Crash report: http_ui show network connections
[
https://issues.apache.org/jira/browse/TS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719154#comment-13719154
]
weijin commented on TS-1223:
@James this patch has been reverted and this bug should have been fixed. so
close it.
> Crash report: http_ui show network connections
> --
>
> Key: TS-1223
> URL: https://issues.apache.org/jira/browse/TS-1223
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Management, Network
>Affects Versions: 3.1.3
> Environment: git master with http_ui enabled
>Reporter: Zhao Yongming
>Assignee: Bin Chen
> Fix For: 3.3.1
>
> Attachments: show_net.patch
>
>
> {code}
> (gdb) bt
> #0 0x0032ee248097 in vfprintf () from /lib64/libc.so.6
> #1 0x0032ee26f052 in vsnprintf () from /lib64/libc.so.6
> #2 0x005ef411 in ShowCont::show(char const*, ...) ()
> #3 0x00699d67 in ShowNet::showConnectionsOnThread(int, Event*) ()
> #4 0x006a8104 in handleEvent (this=0x2abe3bafb010, e=0x2abee001cb70,
> calling_code=1) at I_Continuation.h:146
> #5 EThread::process_event (this=0x2abe3bafb010, e=0x2abee001cb70,
> calling_code=1) at UnixEThread.cc:142
> #6 0x006a8b7b in EThread::execute (this=0x2abe3bafb010) at
> UnixEThread.cc:191
> #7 0x006a7042 in spawn_thread_internal (a=0x188e600) at Thread.cc:88
> #8 0x0032eea077e1 in start_thread () from /lib64/libpthread.so.0
> #9 0x0032ee2e68ed in clone () from /lib64/libc.so.6
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2027) there`s no initializer of ConnectionCount`s mutex
[ https://issues.apache.org/jira/browse/TS-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin resolved TS-2027. Resolution: Fixed Fix Version/s: (was: 3.3.5) Assignee: weijin > there`s no initializer of ConnectionCount`s mutex > - > > Key: TS-2027 > URL: https://issues.apache.org/jira/browse/TS-2027 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Attachments: TS-2027.diff > > > the mutex of ConnectionCount should be initialized before used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2027) there`s no initializer of ConnectionCount`s mutex
[ https://issues.apache.org/jira/browse/TS-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-2027: --- Attachment: TS-2027.diff > there`s no initializer of ConnectionCount`s mutex > - > > Key: TS-2027 > URL: https://issues.apache.org/jira/browse/TS-2027 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin > Attachments: TS-2027.diff > > > the mutex of ConnectionCount should be initialized before used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2027) there`s no initializer of ConnectionCount`s mutex
weijin created TS-2027: -- Summary: there`s no initializer of ConnectionCount`s mutex Key: TS-2027 URL: https://issues.apache.org/jira/browse/TS-2027 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin the mutex of ConnectionCount should be initialized before used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1660) Host field should not have c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13670309#comment-13670309 ] weijin commented on TS-1660: Leif, It is from the client input, maybe malicious attacks. > Host field should not have c style terminator > -- > > Key: TS-1660 > URL: https://issues.apache.org/jira/browse/TS-1660 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: Leif Hedstrom > Labels: A > Fix For: 3.3.3 > > Attachments: ts-1660.diff > > > if host field of client has c style terminator, it may lead to serious > problems (e.g. ats use c string to do hostdb lookup). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin updated TS-1917:
---
Attachment: ts-1917.wj.diff
> It seems that one of assert in HttpTransact::handle_content_length_header()
> is unnecessary
> ---
>
> Key: TS-1917
> URL: https://issues.apache.org/jira/browse/TS-1917
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Yunkai Zhang
> Attachments: ts-1917.wj.diff
>
>
> ATS crashed by the following assert in debug mode:
> {code}
> (gdb) bt
> #0 0x003e86c32885 in raise () from /lib64/libc.so.6
> #1 0x003e86c34065 in abort () from /lib64/libc.so.6
> #2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1,
> message_format=0x2b349594a748 "%s:%d: failed assert `%s`",
> ap=0x2b34979073a0) at ink_error.cc:65
> #4 0x2b349592e3ca in ink_fatal (return_code=1,
> message_format=0x2b349594a748 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 "s->range_setup !=
> RANGE_NOT_TRANSFORM_REQUESTED", file=0x70a613 "HttpTransact.cc", line=6660)
> at ink_assert.cc:37
> #6 0x0059cb57 in HttpTransact::handle_content_length_header
> (s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
> HttpTransact.cc:6660
> #7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
> base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
> outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
> "OK") at HttpTransact.cc:7731
> #8 0x00594972 in
> HttpTransact::handle_cache_operation_on_forward_server_response
> (s=0x2b34b1207120) at HttpTransact.cc:4373
> #9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
> (s=0x2b34b1207120) at HttpTransact.cc:3818
> #10 0x00590c08 in HttpTransact::handle_response_from_server
> (s=0x2b34b1207120) at HttpTransact.cc:3495
> #11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
> HttpTransact.cc:3185
> #12 0x00575f25 in HttpSM::call_transact_and_set_next_state
> (this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
> #13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
> HttpSM.cc:1555
> #14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
> event=0, data=0x0) at HttpSM.cc:1487
> #15 0x0056f79b in HttpSM::do_api_callout_internal
> (this=0x2b34b12070b0) at HttpSM.cc:4702
> #16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
> HttpSM.cc:503
> #17 0x00564b68 in HttpSM::state_read_server_response_header
> (this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
> #18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
> event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
> #19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
> event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x006ba540 in read_signal_and_update (event=100,
> vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
> #21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
> vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
> #22 0x006bcc7f in UnixNetVConnection::net_read_io
> (this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
> UnixNetVConnection.cc:818
> #23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
> event=5, e=0x2b349cf16b40) at UnixNet.cc:377
> #24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
> event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
> #25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
> e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
> #26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
> UnixEThread.cc:265
> #27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
> #28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> {code}
> By analyzing the code, it seems that this assertion is unnecessary:
> When client sends a request to ATS, and the content hits in cache, but if the
> cache is STALE, ATS will sent a request to Original-Server.
> In this case, the t_sate.source will be updated to
> SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
> HttpTransact::handle_cache_operation_on_forward_server_response()
> => s->state_machine->do_range_setup_if_necessary(), the s->range_setup could
> be updated to RANGE_NOT_TRANSFORM_REQU
[jira] [Commented] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663985#comment-13663985
]
weijin commented on TS-1917:
this is a bug that if it is a header only update (server response 304), then
the body is served from cache, I think we should set the t_state.source as
SOURCE_CACHE. any idea ?
> It seems that one of assert in HttpTransact::handle_content_length_header()
> is unnecessary
> ---
>
> Key: TS-1917
> URL: https://issues.apache.org/jira/browse/TS-1917
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Yunkai Zhang
>
> ATS crashed by the following assert in debug mode:
> {code}
> (gdb) bt
> #0 0x003e86c32885 in raise () from /lib64/libc.so.6
> #1 0x003e86c34065 in abort () from /lib64/libc.so.6
> #2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1,
> message_format=0x2b349594a748 "%s:%d: failed assert `%s`",
> ap=0x2b34979073a0) at ink_error.cc:65
> #4 0x2b349592e3ca in ink_fatal (return_code=1,
> message_format=0x2b349594a748 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 "s->range_setup !=
> RANGE_NOT_TRANSFORM_REQUESTED", file=0x70a613 "HttpTransact.cc", line=6660)
> at ink_assert.cc:37
> #6 0x0059cb57 in HttpTransact::handle_content_length_header
> (s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
> HttpTransact.cc:6660
> #7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
> base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
> outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
> "OK") at HttpTransact.cc:7731
> #8 0x00594972 in
> HttpTransact::handle_cache_operation_on_forward_server_response
> (s=0x2b34b1207120) at HttpTransact.cc:4373
> #9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
> (s=0x2b34b1207120) at HttpTransact.cc:3818
> #10 0x00590c08 in HttpTransact::handle_response_from_server
> (s=0x2b34b1207120) at HttpTransact.cc:3495
> #11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
> HttpTransact.cc:3185
> #12 0x00575f25 in HttpSM::call_transact_and_set_next_state
> (this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
> #13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
> HttpSM.cc:1555
> #14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
> event=0, data=0x0) at HttpSM.cc:1487
> #15 0x0056f79b in HttpSM::do_api_callout_internal
> (this=0x2b34b12070b0) at HttpSM.cc:4702
> #16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
> HttpSM.cc:503
> #17 0x00564b68 in HttpSM::state_read_server_response_header
> (this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
> #18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
> event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
> #19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
> event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x006ba540 in read_signal_and_update (event=100,
> vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
> #21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
> vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
> #22 0x006bcc7f in UnixNetVConnection::net_read_io
> (this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
> UnixNetVConnection.cc:818
> #23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
> event=5, e=0x2b349cf16b40) at UnixNet.cc:377
> #24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
> event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
> #25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
> e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
> #26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
> UnixEThread.cc:265
> #27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
> #28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> {code}
> By analyzing the code, it seems that this assertion is unnecessary:
> When client sends a request to ATS, and the content hits in cache, but if the
> cache is STALE, ATS will sent a request to Original-Server.
> In this case, the t_sate.source will be updated to
> SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
> HttpTransac
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662756#comment-13662756 ] weijin commented on TS-745: --- the ssd is treated as the (block) cache of hdd disk, and the ssd dir will be cleared when you start (restart) ats, so it also can unplug any hdd disk and change it back. I admit this patch is pretty invasive and make cache more complicated, and I appropriate that someone can give us a more general and elegant design of tired cache solution. > Support ssd > --- > > Key: TS-745 > URL: https://issues.apache.org/jira/browse/TS-745 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: mohan_zl >Assignee: weijin > Fix For: 3.3.5 > > Attachments: 0001-TS-745-support-interim-caching-in-storage.patch, > ts-745.diff, TS-ssd-2.patch, TS-ssd.patch > > > A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
[ https://issues.apache.org/jira/browse/TS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655838#comment-13655838 ] weijin commented on TS-1601: we only can call do_io_* when we acquired the bucket`s lock. If we simply disable vc->read.enabled and vc->write.enabled when we not acquired the bucket`s lock, but still can not prevent the net_vc timeout events. > HttpServerSession::release don't close ServerSession if ServerSessionPool > locking contention > > > Key: TS-1601 > URL: https://issues.apache.org/jira/browse/TS-1601 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Fix For: 3.3.1 > > Attachments: TS-1601.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
[ https://issues.apache.org/jira/browse/TS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655741#comment-13655741 ] weijin commented on TS-1601: this patch have race and may lead ts crash. > HttpServerSession::release don't close ServerSession if ServerSessionPool > locking contention > > > Key: TS-1601 > URL: https://issues.apache.org/jira/browse/TS-1601 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen >Priority: Minor > Fix For: 3.3.1 > > Attachments: TS-1601.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1601) HttpServerSession::release don't close ServerSession if ServerSessionPool locking contention
[
https://issues.apache.org/jira/browse/TS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655742#comment-13655742
]
weijin commented on TS-1601:
(gdb) bt
#0 0x006560d7 in operator IOBufferBlock* (nh=0x2b06bc845bc0,
vc=0x2b08315f41c0, thread=)
at ../../lib/ts/Ptr.h:318
#1 read_from_net (nh=0x2b06bc845bc0, vc=0x2b08315f41c0, thread=) at UnixNetVConnection.cc:243
#2 0x0064d74a in NetHandler::mainNetEvent (this=0x2b06bc845bc0,
event=, e=)
at UnixNet.cc:377
#3 0x00674806 in handleEvent (this=0x2b06bc842010, e=0x2b06bf576cc0,
calling_code=5) at I_Continuation.h:146
#4 EThread::process_event (this=0x2b06bc842010, e=0x2b06bf576cc0,
calling_code=5) at UnixEThread.cc:141
#5 0x00675833 in EThread::execute (this=0x2b06bc842010) at
UnixEThread.cc:265
#6 0x006739ba in spawn_thread_internal (a=0x1742160) at Thread.cc:88
#7 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
#8 0x003e86ce5ccd in clone () from /lib64/libc.so.6
(gdb) f 1
#1 read_from_net (nh=0x2b06bc845bc0, vc=0x2b08315f41c0, thread=) at UnixNetVConnection.cc:243
243 IOBufferBlock *b = buf.mbuf->_writer;
(gdb) p vc->read.vio
$2 = {_cont = 0x182da78, nbytes = 0, ndone = 0, op = 1, buffer = {mbuf = 0x0,
entry = 0x0, name = 0x0}, vc_server = 0x2b08315f41c0,
mutex = {m_ptr = 0x2b06bc63ea00}}
(gdb) p vc->read.vio._cont->handler
$3 = (int (Continuation::*)(Continuation *, int, void *)) 0x50ba30
> HttpServerSession::release don't close ServerSession if ServerSessionPool
> locking contention
>
>
> Key: TS-1601
> URL: https://issues.apache.org/jira/browse/TS-1601
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: Bin Chen
>Priority: Minor
> Fix For: 3.3.1
>
> Attachments: TS-1601.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1821) AIO tests don't build with native AIO
[ https://issues.apache.org/jira/browse/TS-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1821: --- Attachment: ts-1821.wj.diff jpeach: please review and make sure whether the aio unit test passed or not. > AIO tests don't build with native AIO > - > > Key: TS-1821 > URL: https://issues.apache.org/jira/browse/TS-1821 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: weijin > Fix For: 3.3.3 > > Attachments: ts-1821.wj.diff > > > /opt/src/trafficserver.git/configure --prefix=/opt/ats > --enable-linux-native-aio && make -j 4 && make check > test_AIO-test_AIO.o: In function `main': > /opt/src/trafficserver.git/iocore/aio/test_AIO.cc:498: undefined reference to > `cache_config_threads_per_disk' > collect2: error: ld returned 1 exit status -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1821) AIO tests don't build with native AIO
[ https://issues.apache.org/jira/browse/TS-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633537#comment-13633537 ] weijin commented on TS-1821: I thought the global variable cache_config_threads_per_disk may have no use if we --enable-linux-native-aio, seems I made a mistake. > AIO tests don't build with native AIO > - > > Key: TS-1821 > URL: https://issues.apache.org/jira/browse/TS-1821 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: weijin > Fix For: 3.3.3 > > > /opt/src/trafficserver.git/configure --prefix=/opt/ats > --enable-linux-native-aio && make -j 4 && make check > test_AIO-test_AIO.o: In function `main': > /opt/src/trafficserver.git/iocore/aio/test_AIO.cc:498: undefined reference to > `cache_config_threads_per_disk' > collect2: error: ld returned 1 exit status -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1816) active_timeout may lead TS crash
weijin created TS-1816: -- Summary: active_timeout may lead TS crash Key: TS-1816 URL: https://issues.apache.org/jira/browse/TS-1816 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin 1: client request with 'If-Modified-Since' 2: ts has no copy in the cache and prepare for cache write 3: ts send server without the field 'If-Modified-Since' 4: server response hdr is back (200 0K) 5: suppose the request`s If-Modified-Since < reponse`s Last-Modified, ts will send client 304 back(HttpSM::setup_internal_transfer) 6: ts will do the tunnel_handler_cache_fill to write the response to cache the is a problem in step 5 and step 6. In step 5, all the event`s associated by server_session is also handled by HttpSM::state_read_server_response_header rather than the tunnel, which may lead to serious problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630067#comment-13630067 ] weijin commented on TS-608: --- since chenbin is going to handle the session management stuff, assign to him. :) > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Bin Chen > Fix For: 3.3.3 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-608: -- Assignee: Bin Chen > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Bin Chen > Fix For: 3.3.3 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1760) use linux native aio
[ https://issues.apache.org/jira/browse/TS-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622427#comment-13622427 ] weijin commented on TS-1760: the timeout of io_getevents is 0, so it is never blocked. > use linux native aio > > > Key: TS-1760 > URL: https://issues.apache.org/jira/browse/TS-1760 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: weijin >Assignee: weijin > Fix For: 3.3.2 > > Attachments: native_aio.patch > > > add a feature that use linux native aio -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-745: -- Attachment: ts-745.diff make the ssd as cache of sas disks. steal 4 bits from the dir. 1 bit to identify the dir is for ssd or sas; 3 bits to index which ssd vol. Migrate to ssd based on fragment rather than document. need more reviews and comments > Support ssd > --- > > Key: TS-745 > URL: https://issues.apache.org/jira/browse/TS-745 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: mohan_zl >Assignee: weijin > Fix For: 3.3.4 > > Attachments: ts-745.diff, TS-ssd-2.patch, TS-ssd.patch > > > A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[
https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619555#comment-13619555
]
weijin commented on TS-1713:
virtual size_t estimated_heap_bytes_per_entry() const { return
sizeof(HostDBInfo) * 2 + 512; }
sorry, I made a mistake.
if we config 12 entries. then the hostdb has
12 entries for level1, (12 * 64)
15000 entries for level0, (15000 * 64)
and
estimated_heap_bytes_per_entry * (12 + 15000) for heap
the total size is 64 * 12 + 64 * 15000 + 640 * 135000 = 9504 (90M)
so total storage 100M is enough.
> Querying SRV record doesn't work
>
>
> Key: TS-1713
> URL: https://issues.apache.org/jira/browse/TS-1713
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Li-Wen Hsu
>Assignee: weijin
> Fix For: 3.3.2
>
> Attachments: support_srv.patch, ts-1713.diff
>
>
> For ATS > 3.0.x, when setting "CONFIG proxy.config.srv_enabled INT 1" in
> records.config , ATS blocks and return nothing to client, even no 404.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1777) can not build on 32 bit system
[ https://issues.apache.org/jira/browse/TS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614132#comment-13614132 ] weijin commented on TS-1777: 32 bit ubuntu 12.10 > can not build on 32 bit system > -- > > Key: TS-1777 > URL: https://issues.apache.org/jira/browse/TS-1777 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: weijin > Attachments: ts-1777.diff > > > ats can not build on 32 bit system because of TS-1742 (volatile key word > removed). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1777) can not build on 32 bit system
[ https://issues.apache.org/jira/browse/TS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614113#comment-13614113 ] weijin commented on TS-1777: the same as the cas128 for 64 bit system, should we also use cas64 for 32 bit system ? another question, the cas of 64 bit data (for 32 bit) or 128 bit data (for 64 bit) really necessary ? the last question, can we ensure the correctness by inserting a memory barrier between the loads of the version and the pointer ? > can not build on 32 bit system > -- > > Key: TS-1777 > URL: https://issues.apache.org/jira/browse/TS-1777 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: weijin > Attachments: ts-1777.diff > > > ats can not build on 32 bit system because of TS-1742 (volatile key word > removed). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1777) can not build on 32 bit system
[ https://issues.apache.org/jira/browse/TS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1777: --- Attachment: ts-1777.diff > can not build on 32 bit system > -- > > Key: TS-1777 > URL: https://issues.apache.org/jira/browse/TS-1777 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: weijin > Attachments: ts-1777.diff > > > ats can not build on 32 bit system because of TS-1742 (volatile key word > removed). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1777) can not build on 32 bit system
weijin created TS-1777: -- Summary: can not build on 32 bit system Key: TS-1777 URL: https://issues.apache.org/jira/browse/TS-1777 Project: Traffic Server Issue Type: Bug Components: Build Reporter: weijin ats can not build on 32 bit system because of TS-1742 (volatile key word removed). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1546) endless loop in unmashual may cause throttling
[ https://issues.apache.org/jira/browse/TS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609044#comment-13609044 ] weijin commented on TS-1546: after dig it more, we found the root cause of the endless loop is the cache was polluted. So I think maybe we can close it now. > endless loop in unmashual may cause throttling > -- > > Key: TS-1546 > URL: https://issues.apache.org/jira/browse/TS-1546 > Project: Traffic Server > Issue Type: Sub-task > Components: Cache, HTTP >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 3.3.2 > > > we get a thread looping in the HdrHeap::unmarshal, while m_length is 0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1767) Cache Lookup Regex using incorrect urls
[ https://issues.apache.org/jira/browse/TS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608616#comment-13608616 ] weijin commented on TS-1767: traffic_line -s proxy.config.url_remap.pristine_host_hdr -v 0 > Cache Lookup Regex using incorrect urls > --- > > Key: TS-1767 > URL: https://issues.apache.org/jira/browse/TS-1767 > Project: Traffic Server > Issue Type: Bug > Components: Web UI >Reporter: Scott Harris > > When using the cache regex lookup returned urls contain origin server not of > incoming mapping to ats. > Ie using map http://incoming http://10.1.1.1:8080 > returned regex urls are : http://10.1.1.1:8080/ instead of > http://incoming/ > Selecting any of these results in "Cache Lookup Failed, or missing in cluster" > Doing url lookup with incoming url returns valid result. > Using version 3.2.4 running as a reverse proxy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1635) url parse BUGS IN Apache Traffic Sever 3.3.1
[ https://issues.apache.org/jira/browse/TS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607615#comment-13607615 ] weijin commented on TS-1635: [~evilabandon] I did a debug by using your case, and still not see the phenomenon you mentioned. Maybe the bug is in logging rather than in hdr parse. > url parse BUGS IN Apache Traffic Sever 3.3.1 > - > > Key: TS-1635 > URL: https://issues.apache.org/jira/browse/TS-1635 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: evilbandon >Assignee: weijin > Fix For: 3.3.3 > > > url parse BUGS IN Apache Traffic Sever 3.3.1 > the request URL is http://a.b.com/xx.jpg?newpath=http://b.c.com > but the Apache Traffic Sever 3.3.1 parse this url as http://b.c.com -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1760) use linux native aio
[ https://issues.apache.org/jira/browse/TS-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1760: --- Attachment: native_aio.patch > use linux native aio > > > Key: TS-1760 > URL: https://issues.apache.org/jira/browse/TS-1760 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: weijin > Attachments: native_aio.patch > > > add a feature that use linux native aio -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1760) use linux native aio
weijin created TS-1760: -- Summary: use linux native aio Key: TS-1760 URL: https://issues.apache.org/jira/browse/TS-1760 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: weijin Attachments: native_aio.patch add a feature that use linux native aio -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1760) use linux native aio
[ https://issues.apache.org/jira/browse/TS-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607196#comment-13607196 ] weijin commented on TS-1760: @John, please take a time to review and test it. > use linux native aio > > > Key: TS-1760 > URL: https://issues.apache.org/jira/browse/TS-1760 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: weijin > Attachments: native_aio.patch > > > add a feature that use linux native aio -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1602) crash at http_hdr_type_get
[
https://issues.apache.org/jira/browse/TS-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607184#comment-13607184
]
weijin commented on TS-1602:
It arise in our production environment, but I have no idea how to reproduce it.
sigh
> crash at http_hdr_type_get
> --
>
> Key: TS-1602
> URL: https://issues.apache.org/jira/browse/TS-1602
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, MIME
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: taorui
> Labels: crash
> Fix For: sometime
>
>
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.47.el6.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> ncurses-libs-5.7-3.20090208.el6.x86_64 openssl-1.0.0-20.el6.x86_64
> pcre-7.8-3.1.el6.x86_64 readline-6.0-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
> xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> #1 0x005034d2 in HTTPHdr::type_get (this=0x2ba4d149f088) at
> hdrs/HTTP.h:967
> #2 0x0058e6f4 in HttpTransact::HandleCacheOpenRead
> (s=0x2ba51d5d2838) at HttpTransact.cc:2046
> #3 0x0057af93 in HttpSM::call_transact_and_set_next_state
> (this=0x2ba51d5d27d0,
> f=0x58e5cc ) at
> HttpSM.cc:6425
> #4 0x0056e576 in HttpSM::state_cache_open_read (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10)
> at HttpSM.cc:2406
> #5 0x0056e968 in HttpSM::main_handler (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10) at HttpSM.cc:2465
> #6 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d27d0,
> event=1102, data=0x2ba3f8d00c10)
> at ../iocore/eventsystem/I_Continuation.h:146
> #7 0x00556f02 in HttpCacheSM::state_cache_open_read
> (this=0x2ba51d5d4898, event=1102, data=0x2ba3f8d00c10)
> at HttpCacheSM.cc:118
> #8 0x004e6fae in Continuation::handleEvent (this=0x2ba51d5d4898,
> event=1102, data=0x2ba3f8d00c10)
> at ../iocore/eventsystem/I_Continuation.h:146
> #9 0x00649779 in CacheContinuation::callback_user
> (this=0x2ba410a95560, res=1102, e=0x2ba3f8d00c10)
> at ClusterCache.cc:2813
> #10 0x00648433 in CacheContinuation::remoteOpEvent
> (this=0x2ba410a95560, event_code=1151, e=0x2ba4d149f000)
> at ClusterCache.cc:2345
> #11 0x004e6fae in Continuation::handleEvent (this=0x2ba410a95560,
> event=1151, data=0x2ba4d149f000)
> at ../iocore/eventsystem/I_Continuation.h:146
> #12 0x0064751c in cache_op_result_ClusterFunction (ch=0x2ba428881140,
> d=0x2ba570cd4018, l=2776)
> at ClusterCache.cc:2088
> #13 0x00651747 in ClusterHandler::process_incoming_callouts
> (this=0x2ba428881140, m=0x2ba3f92a3c50)
> at ClusterHandler.cc:1237
> #14 0x006598db in ClusterCalloutContinuation::CalloutHandler
> (this=0x2ba4284057c0, event=2, e=0x2ba314b48ef0)
> at ClusterHandlerBase.cc:62
> #15 0x004e6fae in Continuation::handleEvent (this=0x2ba4284057c0,
> event=2, data=0x2ba314b48ef0)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x006d99b8 in EThread::process_event (this=0x2ba2cf72e010,
> e=0x2ba314b48ef0, calling_code=2)
> at UnixEThread.cc:189
> #17 0x006dbd79 in PriorityEventQueue::check_ready
> (this=0x2ba2cf82ec40, now=135396960399086, t=0x2ba2cf72e010)
> at PQ-List.cc:141
> #18 0x006d9c8a in EThread::execute (this=0x2ba2cf72e010) at
> UnixEThread.cc:258
> #19 0x006d89e7 in spawn_thread_internal (a=0x15c19a0) at Thread.cc:88
> #20 0x003c088077f1 in start_thread () from /lib64/libpthread.so.0
> #21 0x003c084e570d in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 0x005034b0 in http_hdr_type_get (hh=0x2abf98de9898) at
> hdrs/HTTP.h:957
> /usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:957:28250:beg:0x5034b0
> (gdb) l
> 952
> -*/
> 953
> 954 inline HTTPType
> 955 http_hdr_type_get(HTTPHdrImpl *hh)
> 956 {
> 957 return (hh->m_polarity);
> 958 }
> 959
> 960
> /*-
> 961
> -*/
> (gdb) p hh->m_polarity
> Cannot access memory at address 0x2abf98de98
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604888#comment-13604888 ] weijin commented on TS-1713: 1. the structure HostDBInfo and HostDBRoundRobin is changed for memory saving 2. the srv target`s connection state can be set and clear base on the ip connection state any comments will be appropriated. > Querying SRV record doesn't work > > > Key: TS-1713 > URL: https://issues.apache.org/jira/browse/TS-1713 > Project: Traffic Server > Issue Type: Bug >Reporter: Li-Wen Hsu >Assignee: weijin > Attachments: support_srv.patch, ts-1713.diff > > > For ATS > 3.0.x, when setting "CONFIG proxy.config.srv_enabled INT 1" in > records.config , ATS blocks and return nothing to client, even no 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1713: --- Attachment: support_srv.patch > Querying SRV record doesn't work > > > Key: TS-1713 > URL: https://issues.apache.org/jira/browse/TS-1713 > Project: Traffic Server > Issue Type: Bug >Reporter: Li-Wen Hsu >Assignee: weijin > Attachments: support_srv.patch, ts-1713.diff > > > For ATS > 3.0.x, when setting "CONFIG proxy.config.srv_enabled INT 1" in > records.config , ATS blocks and return nothing to client, even no 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1742) Freelists to use 64bit version w/ Double Word Compare and Swap
[
https://issues.apache.org/jira/browse/TS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598518#comment-13598518
]
weijin commented on TS-1742:
Brian, John, I did a test, the size of assembly codes of ink_freelist_*
function dropped 30%~40% if we removed the volatile in gcc version 4.4.1
> Freelists to use 64bit version w/ Double Word Compare and Swap
> --
>
> Key: TS-1742
> URL: https://issues.apache.org/jira/browse/TS-1742
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Attachments: 128bit_cas.patch, 128bit_cas.patch.2
>
>
> So to those of you familiar with the freelists you know that it works this
> way the head pointer uses the upper 16 bits for a version to prevent the ABA
> problem. The big drawback to this is that it requires the following macros to
> get at the pointer or the version:
> {code}
> #define FREELIST_POINTER(_x) ((void*)(intptr_t)(_x).data)<<16)>>16) | \
> (((~intptr_t)(_x).data)<<16>>63)-1))>>48)<<48))) // sign extend
> #define FREELIST_VERSION(_x) (((intptr_t)(_x).data)>>48)
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).data = intptr_t)(_p))&0xULL) | (((_v)&0xULL)
> << 48))
> {code}
> Additionally, since this only leaves 16 bits it limits the number of versions
> you can have, well more and more x86_64 processors support DCAS (double word
> compare and swap / 128bit CAS). This means that we can use 64bits for a
> version which basically makes the versions unlimited but more importantly it
> takes those macros above and simplifies them to:
> {code}
> #define FREELIST_POINTER(_x) (_x).s.pointer
> #define FREELIST_VERSION(_x) (_x).s.version
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).s.pointer = _p; (_x).s.version = _v
> {code}
> As you can imagine this will have a performance improvement, in my simple
> tests I measured a performance improvement of around 6%. Unfortunately, I'm
> not an expert with this stuff and I would really appreciate more community
> feedback before I commit this patch.
> Note: this only applies if you're not using a reclaimable freelist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1742) Freelists to use 64bit version w/ Double Word Compare and Swap
[
https://issues.apache.org/jira/browse/TS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598486#comment-13598486
]
weijin commented on TS-1742:
should we remove the volatile keyword in head_p structure ？ It seems useless
but generating slow assembly instructions.
> Freelists to use 64bit version w/ Double Word Compare and Swap
> --
>
> Key: TS-1742
> URL: https://issues.apache.org/jira/browse/TS-1742
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Attachments: 128bit_cas.patch, 128bit_cas.patch.2
>
>
> So to those of you familiar with the freelists you know that it works this
> way the head pointer uses the upper 16 bits for a version to prevent the ABA
> problem. The big drawback to this is that it requires the following macros to
> get at the pointer or the version:
> {code}
> #define FREELIST_POINTER(_x) ((void*)(intptr_t)(_x).data)<<16)>>16) | \
> (((~intptr_t)(_x).data)<<16>>63)-1))>>48)<<48))) // sign extend
> #define FREELIST_VERSION(_x) (((intptr_t)(_x).data)>>48)
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).data = intptr_t)(_p))&0xULL) | (((_v)&0xULL)
> << 48))
> {code}
> Additionally, since this only leaves 16 bits it limits the number of versions
> you can have, well more and more x86_64 processors support DCAS (double word
> compare and swap / 128bit CAS). This means that we can use 64bits for a
> version which basically makes the versions unlimited but more importantly it
> takes those macros above and simplifies them to:
> {code}
> #define FREELIST_POINTER(_x) (_x).s.pointer
> #define FREELIST_VERSION(_x) (_x).s.version
> #define SET_FREELIST_POINTER_VERSION(_x,_p,_v) \
> (_x).s.pointer = _p; (_x).s.version = _v
> {code}
> As you can imagine this will have a performance improvement, in my simple
> tests I measured a performance improvement of around 6%. Unfortunately, I'm
> not an expert with this stuff and I would really appreciate more community
> feedback before I commit this patch.
> Note: this only applies if you're not using a reclaimable freelist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1574) Range transform crash at RangeTransform::transform_to_range Transform.cc:842
[
https://issues.apache.org/jira/browse/TS-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin closed TS-1574.
--
Resolution: Fixed
the commit 1199e991424d8495a80075718d8ec95a64f3a712 should have fixed this bug
in master. reopen it if arise again.
> Range transform crash at RangeTransform::transform_to_range Transform.cc:842
>
>
> Key: TS-1574
> URL: https://issues.apache.org/jira/browse/TS-1574
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.3.0
> Environment: git master, forward proxy
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Critical
> Fix For: 3.3.2
>
>
> I have a forward proxy that just updated to the latest git master release on
> 2012-11-16, it crashed several times with the same assert:
> {code}
> Program terminated with signal 11, Segmentation fault.
> #0 RangeTransform::transform_to_range (this=0x2b12603c2c50) at
> Transform.cc:842
> 842 if (*done_byte < (*start - 1)) {
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.47.el6_2.9.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> openssl-1.0.0-20.el6_2.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
> zlib-1.2.3-27.el6.x86_64
> (gdb)
> (gdb) bt
> #0 RangeTransform::transform_to_range (this=0x2b12603c2c50) at
> Transform.cc:842
> #1 0x004da440 in RangeTransform::handle_event (this=0x2b12603c2c50,
> event=, edata=)
> at Transform.cc:815
> #2 0x00654dd4 in handleEvent (this=0x2b1200404010, e=0x2b12841c0ea0,
> calling_code=1) at I_Continuation.h:146
> #3 EThread::process_event (this=0x2b1200404010, e=0x2b12841c0ea0,
> calling_code=1) at UnixEThread.cc:142
> #4 0x0065593b in EThread::execute (this=0x2b1200404010) at
> UnixEThread.cc:193
> #5 0x006540d2 in spawn_thread_internal (a=0x2c987d0) at Thread.cc:88
> #6 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #7 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> (gdb) f 1
> #1 0x004da440 in RangeTransform::handle_event (this=0x2b12603c2c50,
> event=, edata=)
> at Transform.cc:815
> 815 transform_to_range();
> (gdb) l
> 810 m_output_vio->nbytes = m_done;
> 811 m_output_vio->reenable();
> 812 return 0;
> 813 }
> 814
> 815 transform_to_range();
> 816 break;
> 817 }
> 818 }
> 819
> (gdb) p m_output_vio
> $1 = (VIO *) 0x2b12603c2e78
> (gdb) p *m_output_vio
> $2 = {_cont = 0x2b12603c2c50, nbytes = 70664, ndone = 0, op = 2, buffer =
> {mbuf = 0x2b126c0b36e0, entry = 0x2b126c0b36f8},
> vc_server = 0x2b12603c2df8, mutex = {m_ptr = 0x2b12686700e0}}
> (gdb) f 2
> #2 0x00654dd4 in handleEvent (this=0x2b1200404010, e=0x2b12841c0ea0,
> calling_code=1) at I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) l
> 141 @param data General purpose data related to the event code
> (Processor specific).
> 142 @return State machine and processor specific return code.
> 143
> 144 */
> 145 int handleEvent(int event = CONTINUATION_EVENT_NONE, void *data = 0) {
> 146 return (this->*handler) (event, data);
> 147 }
> 148
> 149 /**
> 150 Contructor of the Continuation object. It should not be used
> (gdb) bt
> #0 RangeTransform::transform_to_range (this=0x2b12603c2c50) at
> Transform.cc:842
> #1 0x004da440 in RangeTransform::handle_event (this=0x2b12603c2c50,
> event=, edata=)
> at Transform.cc:815
> #2 0x00654dd4 in handleEvent (this=0x2b1200404010, e=0x2b12841c0ea0,
> calling_code=1) at I_Continuation.h:146
> #3 EThread::process_event (this=0x2b1200404010, e=0x2b12841c0ea0,
> calling_code=1) at UnixEThread.cc:142
> #4 0x0065593b in EThread::execute (this=0x2b1200404010) at
> UnixEThread.cc:193
> #5 0x006540d2 in spawn_thread_internal (a=0x2c987d0) at Thread.cc:88
> #6 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #7 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> (gdb) f 0
> #0 RangeTransform::transform_to_range (this=0x2b12603c2c50) at
> Transform.cc:842
> 842 if (*done_byte < (*start - 1)) {
> (gdb) l
> 837 done_byte = &m_ranges[m_current_range]._done_byte;
> 838 start = &m_ranges[m_current_range]._start;
> 839 avail = reader->read_avail();
> 840
> 841 while (true) {
> 842 if (*done_byte < (*start - 1)) {
> 843 toskip = *start - *done_byte - 1;
> 844
> 845 if (toski
[jira] [Commented] (TS-1713) Querying SRV record doesn't work
[ https://issues.apache.org/jira/browse/TS-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582038#comment-13582038 ] weijin commented on TS-1713: we rewrote the srv completely in our taobao tree and it is running in our production now. I`ll give a patch latter. > Querying SRV record doesn't work > > > Key: TS-1713 > URL: https://issues.apache.org/jira/browse/TS-1713 > Project: Traffic Server > Issue Type: Bug >Reporter: Li-Wen Hsu >Assignee: Alan M. Carroll > Attachments: ts-1713.diff > > > For ATS > 3.0.x, when setting "CONFIG proxy.config.srv_enabled INT 1" in > records.config , ATS blocks and return nothing to client, even no 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1704) Null pointer dereference while debugging is on
[ https://issues.apache.org/jira/browse/TS-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575590#comment-13575590 ] weijin commented on TS-1704: it`s good. thanks for your work. > Null pointer dereference while debugging is on > -- > > Key: TS-1704 > URL: https://issues.apache.org/jira/browse/TS-1704 > Project: Traffic Server > Issue Type: Bug > Components: DNS >Reporter: Li-Wen Hsu > Attachments: > 0001-Fix-null-pointer-dereference-while-HostEnt-ent-is-nu.patch > > > In iocore/dns/DNS.cc:1195, null pointer dereference occurs in > ent->ent.h_addrtype while debugging is on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1653) Crash report: HostDBContinuation::probeEvent MutexTryLock
[
https://issues.apache.org/jira/browse/TS-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572268#comment-13572268
]
weijin commented on TS-1653:
committed bc7a84441ca1d6c13d1117b9515c879c70cf9d3b
> Crash report: HostDBContinuation::probeEvent MutexTryLock
> -
>
> Key: TS-1653
> URL: https://issues.apache.org/jira/browse/TS-1653
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Zhao Yongming
>Assignee: Alan M. Carroll
>
> {code}
> Core was generated by `/usr/bin/traffic_server -M --httpport 8080:fd=7'.
> Program terminated with signal 11, Segmentation fault.
> #0 Mutex_trylock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at
> ../iocore/eventsystem/I_Lock.h:170
> 170 if (m->thread_holding != t) {
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.47.el6_2.9.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> openssl-1.0.0-20.el6_2.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
> zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 Mutex_trylock (this=0x2b994a800ce0, am=0x0, t=0x2b9948fea010) at
> ../iocore/eventsystem/I_Lock.h:170
> #1 MutexTryLock::MutexTryLock (this=0x2b994a800ce0, am=0x0,
> t=0x2b9948fea010) at ../iocore/eventsystem/I_Lock.h:385
> #2 0x005b38dc in HostDBContinuation::probeEvent
> (this=0x2b997329df10, event=, e=0x2b99b8050030) at
> HostDB.cc:1762
> #3 0x0065a1b4 in handleEvent (this=0x2b9948fea010, e=0x2b99b8050030,
> calling_code=2) at I_Continuation.h:146
> #4 EThread::process_event (this=0x2b9948fea010, e=0x2b99b8050030,
> calling_code=2) at UnixEThread.cc:142
> #5 0x0065ad83 in EThread::execute (this=0x2b9948fea010) at
> UnixEThread.cc:221
> #6 0x006594d2 in spawn_thread_internal (a=0x2fb8350) at Thread.cc:88
> #7 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #8 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> (gdb) f 2
> #2 0x005b38dc in HostDBContinuation::probeEvent
> (this=0x2b997329df10, event=, e=0x2b99b8050030) at
> HostDB.cc:1762
> 1762MUTEX_TRY_LOCK_FOR(lock, action.mutex, t, action.continuation);
> (gdb) p action.mutex
> $1 = {m_ptr = 0x0}
> (gdb) p t
> $2 =
> (gdb) p action
> $3 = {_vptr.Action = 0x6601d0, continuation = 0x0, mutex = {m_ptr = 0x0},
> cancelled = 1}
> (gdb)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
[ https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569953#comment-13569953 ] weijin commented on TS-1684: good idea, the call ink_freelist_new/ink_freelist_free can be significantly reduced by making the ProxyAllocator as cache of global freelist. > Reduce the usage of global allocation/free lists - switch to using local > thread allocation/free lists > - > > Key: TS-1684 > URL: https://issues.apache.org/jira/browse/TS-1684 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call > > When running benchmarks ink_freelist_new() normally shows up as one of if not > the number one function in the code using the most CPU. Currently ATS uses > global free lists (via ClassAllocator<>, Allocator, and > SparceClassAllocator<>) for memory allocation for some of its memory > allocation. > Here is a list of how frequently the type of allocations are used and the > "name" given to the allocator. This is a benchmark for a small object in > cache fetched 100k times. > 40 ink_freelist_new: hdrHeap > 30 ink_freelist_new: hdrStrHeap > 203541 ink_freelist_new: ioBlockAllocator > 199616 proxy allocator thread_alloc: eventAllocator > 103554 ink_freelist_new: ioDataAllocator > 103554 ink_freelist_new: ioBufAllocator[5] > 100100 ink_freelist_new: ioAllocator > 10 proxy allocator thread_alloc: hdrHeap > 10 proxy allocator thread_alloc: cacheVConnection > 10 ink_freelist_new: httpSMAllocator > 10 ink_freelist_new: ArenaBlock > 18507 ink_freelist_new: mutexAllocator >4772 ink_freelist_new: eventAllocator > 162 ink_freelist_new: cacheVConnection > 102 ink_freelist_new: netVCAllocator > 100 proxy allocator init thread_alloc: httpClientSessionAllocator > 100 ink_freelist_new: httpClientSessionAllocator > 1 proxy allocator thread_alloc: RamCacheCLFUSEntry > 1 ink_freelist_new: RamCacheCLFUSEntry > 1 ink_freelist_new: hostDBContAllocator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1660) Host field should not has c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1660: --- Attachment: ts-1660.diff > Host field should not has c style terminator > - > > Key: TS-1660 > URL: https://issues.apache.org/jira/browse/TS-1660 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin > Attachments: ts-1660.diff > > > if host field of client has c style terminator, it may lead to serious > problems (e.g. ats use c string to do hostdb lookup). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1660) Host field should not has c style terminator
weijin created TS-1660: -- Summary: Host field should not has c style terminator Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1577) Crash report: RangeTransform::change_response_header at Transform.cc:995
[
https://issues.apache.org/jira/browse/TS-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554655#comment-13554655
]
weijin commented on TS-1577:
committed 1199e991424d8495a80075718d8ec95a64f3a712
> Crash report: RangeTransform::change_response_header at Transform.cc:995
>
>
> Key: TS-1577
> URL: https://issues.apache.org/jira/browse/TS-1577
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.3.0
> Environment: git master version
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Critical
> Fix For: 3.3.1
>
> Attachments: ts-1574.diff
>
>
> This may or may not relate to TS-1574, I'd like track this issue another
> thread here.
> {code}
> Core was generated by `/usr/bin/traffic_server -M --httpport 8080:fd=12'.
> Program terminated with signal 6, Aborted.
> #0 0x003e86c32885 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> expat-2.0.1-11.el6_2.x86_64 glibc-2.12-1.47.el6_2.9.x86_64
> keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64
> libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64
> libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64
> openssl-1.0.0-20.el6_2.4.x86_64 pcre-7.8-3.1.el6.x86_64
> tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64
> zlib-1.2.3-27.el6.x86_64
> (gdb) bt
> #0 0x003e86c32885 in raise () from /lib64/libc.so.6
> #1 0x003e86c34065 in abort () from /lib64/libc.so.6
> #2 0x0035c8013f19 in ink_die_die_die (retval=30342) at ink_error.cc:43
> #3 0x0035c8014194 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1,
> message_format=, ap=0x2b0b8fcc3ba0) at
> ink_error.cc:65
> #4 0x0035c80142c8 in ink_fatal (return_code=30342, message_format=0x7693
> ) at ink_error.cc:73
> #5 0x0035c8012c3f in _ink_assert (expression=0x0, file=0x6 out of bounds>, line=-1) at ink_assert.cc:38
> #6 0x004d671c in RangeTransform::change_response_header
> (this=0x2b0be4500bf0) at Transform.cc:995
> #7 0x004da4cd in RangeTransform::handle_event (this=0x2b0be4500bf0,
> event=, edata=)
> at Transform.cc:791
> #8 0x00654dd4 in handleEvent (this=0x2b0b8e4ad010, e=0x34aff40,
> calling_code=1) at I_Continuation.h:146
> #9 EThread::process_event (this=0x2b0b8e4ad010, e=0x34aff40, calling_code=1)
> at UnixEThread.cc:142
> #10 0x0065593b in EThread::execute (this=0x2b0b8e4ad010) at
> UnixEThread.cc:193
> #11 0x006540d2 in spawn_thread_internal (a=0x2c79a50) at Thread.cc:88
> #12 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #13 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> (gdb) f 6
> #6 0x004d671c in RangeTransform::change_response_header
> (this=0x2b0be4500bf0) at Transform.cc:995
> 995
> ink_release_assert(m_transform_resp->field_find(MIME_FIELD_CONTENT_RANGE,
> MIME_LEN_CONTENT_RANGE) == NULL);
> (gdb) p this
> $1 = (RangeTransform * const) 0x2b0be4500bf0
> (gdb) p *this
> $2 = { = { = { =
> { = { = { = {
> _vptr.force_VFPT_to_top = 0x667970}, handler = (int
> (Continuation::*)(Continuation *, int,
> void *)) 0x4da200 , mutex =
> {m_ptr = 0x2b0bf8216110}, link = {> = {next = 0x0},
> prev = 0x0}}, lerrno = 0}, }, mdata = 0x0,
> m_event_func = 0, m_event_count = 0, m_closed = 0, m_deletable = 0,
> m_deleted = 0, m_free_magic = INKCONT_INTERN_MAGIC_ALIVE}, m_read_vio =
> {_cont = 0x0, nbytes = 0, ndone = 0, op = 0, buffer = {mbuf = 0x0,
> entry = 0x0}, vc_server = 0x0, mutex = {m_ptr = 0x0}}, m_write_vio =
> {_cont = 0x2b0f9168f020, nbytes = 20480, ndone = 0, op = 2, buffer = {
> mbuf = 0x2b0c0407fdd0, entry = 0x2b0c0407fe10}, vc_server =
> 0x2b0be4500bf0, mutex = {m_ptr = 0x2b0bf8216110}},
> m_output_vc = 0x2b0be459f048}, m_output_buf = 0x33b7ca0, m_output_reader
> = 0x33b7cb8, m_transform_resp = 0x2b0f9168dc88,
> m_output_vio = 0x2b0be459f0c8, m_unsatisfiable_range = false,
> m_range_content_length = 0, m_num_chars_for_cl = 1, m_num_range_fields = -1,
> m_current_range = 0,
> m_content_type = 0x2b1216ea6ac0 "application/octet-stream\r\nContent-Range:
> bytes 0-20479/119091\r\nContent-Length: 20480\r\nConnection:
> keep-alive\r\nDate: Sun, 18 Nov 2012 13:30:05 GMT\r\nServer:
> apache\r\n\r\n\343k\031P", m_content_type_len = 24, m_ranges =
> 0x2b0be45bda90,
> m_output_cl = 20480, m_done = 0}
> (gdb) p m_ranges
> $3 = (RangeRecord *) 0x2b0be45bda90
> (gdb) p *m_ranges
> $4 = {_start = 20480, _end = 40959, _done_byte = -1}
> (gdb) p *m_transform_resp
> $1 = { = { = {m_heap = 0x2b0f914ec010}, m_mime =
> 0x2b0f914ec0c8}, m_http
