[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
portl4t updated TS-3198:
------------------------
Attachment: 0001-TS-3198-Ignore-useless-MIMEFieldBlockImpl.patch
> Ignore useless MIMEFieldBlockImpl.
> ----------------------------------
>
> Key: TS-3198
> URL: https://issues.apache.org/jira/browse/TS-3198
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
> Reporter: portl4t
> 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)
