[jira] [Commented] (TS-3198) Ignore useless MIMEFieldBlockImpl.

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474166#comment-15474166 ] 

Leif Hedstrom commented on TS-3198:
-----------------------------------

[~gancho] Thoughts on this? Shall we land it? Or move out to 7.1.0?

> Ignore useless MIMEFieldBlockImpl.
> ----------------------------------
>
>                 Key: TS-3198
>                 URL: https://issues.apache.org/jira/browse/TS-3198
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: MIME
>    Affects Versions: 4.1.2, 4.2.0, 4.2.2, 5.0.0, 5.1.1
>            Reporter: portl4t
>            Assignee: Gancho Tenev
>             Fix For: 7.0.0
>
>         Attachments: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
>
>
> ATS will generate a very large marshal header in a rare case. As we know, ATS will merge the response header if it get 304 from origin server. I found that the HdrHeap size will increase if duplidated header exist.
> In our production environment, we got a response from origin server like this:
> {code}
> HTTP/1.1 200 OK
> Content-Length: 60
> ...
> Powered-By-CC: MISS from A
> Cache-Control: public,max-age=0
> Powered-By-CC: MISS from B
> Connection: close
> {code}
> There is a duplicated header 'Powered-By-CC', and every time the doc had been accessed, ATS had to revalidate this doc from the origin as the max-age is 0. The origin server response 304 like this:
> {code}
> HTTP/1.1 304 Not Modified
> ...
> Powered-By-CC: 8c61e322f02a0343e93ef227d82e5e0a
> Cache-Control: public,max-age=0
> Powered-By-CC: e4563610a50c63ed500d27bb5f1df848
> Connection: close
> {code}
> ATS will merge the header frequently, and the HdrHeap size will increase endlessly.
> {code}
> Breakpoint 1, CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:132
> 132     header_len = write_vector->marshal_length();
> (gdb) n
> 133     od->writing_vec = 1;
> (gdb) p header_len
> $1 = 1068944
> (gdb) bt
> #0  CacheVC::updateVector (this=0x14112f0) at CacheWrite.cc:133
> #1  0x00000000006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0, e=0x0) at CacheWrite.cc:1276
> #2  0x000000000069e827 in CacheVC::die (this=0x14112f0) at P_CacheInternal.h:738
> #3  0x0000000000690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1) at Cache.cc:373
> #4  0x00000000004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0, nbytes=9223372036854775807, cb=0x0, data=0)
>     at ../iocore/eventsystem/P_VConnection.h:106
> #5  0x0000000000591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at HttpCacheSM.h:118
> #6  0x00000000005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at HttpSM.cc:5590
> #7  0x00000000005895d6 in HttpSM::perform_cache_write_action (this=0x7fffe7f7b980) at HttpSM.cc:5540
> #8  0x000000000058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at HttpSM.cc:7206
> #9  0x000000000058e0be in HttpSM::call_transact_and_set_next_state (this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
> #10 0x000000000057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at HttpSM.cc:1531
> #11 0x00000000005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at HttpSM.cc:452
> #12 0x000000000057cf73 in HttpSM::state_read_server_response_header (this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
> #13 0x000000000057f536 in HttpSM::main_handler (this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
> #14 0x00000000004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
> #15 0x00000000006ead77 in read_signal_and_update (event=100, vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
> #16 0x00000000006eb5a7 in read_from_net (nh=0x7ffff37cea30, vc=0x7fffe0015b60, thread=0x7ffff37cb010) at UnixNetVConnection.cc:320
> #17 0x00000000006ed221 in UnixNetVConnection::net_read_io (this=0x7fffe0015b60, nh=0x7ffff37cea30, lthread=0x7ffff37cb010) at UnixNetVConnection.cc:846
> #18 0x00000000006e4dd1 in NetHandler::mainNetEvent (this=0x7ffff37cea30, event=5, e=0x1089e80) at UnixNet.cc:399
> #19 0x00000000004f55a6 in Continuation::handleEvent (this=0x7ffff37cea30, event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x000000000070bace in EThread::process_event (this=0x7ffff37cb010, e=0x1089e80, calling_code=5) at UnixEThread.cc:144
> #21 0x000000000070bfd8 in EThread::execute (this=0x7ffff37cb010) at UnixEThread.cc:268
> #22 0x0000000000526644 in main (argv=0x7fffffffe368) at Main.cc:1763
> {code}
> In HttpTransact::merge_response_header_with_cached_header(...), ATS will set the old MIMEField as DELETED if it is duplicated, and attach new MIMEField, this will increase the number of MIMEFieldBlockImpl, and the HdrHeap size may increase to larger than 1M.
> I suggest to ignore the useless MIMEFieldBlockImpl when copy the MIME header in mime_hdr_copy_onto(...).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)