[jira] [Updated] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3198:
--
Fix Version/s: 5.2.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
Fix For: 5.2.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 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) 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)
[jira] [Commented] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213699#comment-14213699
]
Leif Hedstrom commented on TS-3198:
---
Brian can you review this please?
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: Brian Geffon
Fix For: 5.2.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 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) 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)
[jira] [Updated] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3198:
--
Assignee: Brian Geffon
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: Brian Geffon
Fix For: 5.2.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 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) 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)
[jira] [Commented] (TS-3198) Ignore useless MIMEFieldBlockImpl.
[
https://issues.apache.org/jira/browse/TS-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213831#comment-14213831
]
portl4t commented on TS-3198:
-
I just provide a method to solve this problem, and I think there will be better
ways.
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: Brian Geffon
Fix For: 5.2.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 0x006c04c6 in CacheVC::openWriteClose (this=0x14112f0, event=0,
e=0x0) at CacheWrite.cc:1276
#2 0x0069e827 in CacheVC::die (this=0x14112f0) at
P_CacheInternal.h:738
#3 0x00690b1f in CacheVC::do_io_close (this=0x14112f0, alerrno=-1)
at Cache.cc:373
#4 0x004fed48 in VConnection::do_io (this=0x14112f0, op=3, c=0x0,
nbytes=9223372036854775807, cb=0x0, data=0)
at ../iocore/eventsystem/P_VConnection.h:106
#5 0x00591b5a in HttpCacheSM::close_write (this=0x7fffe7f7d3b0) at
HttpCacheSM.h:118
#6 0x005897a9 in HttpSM::issue_cache_update (this=0x7fffe7f7b980) at
HttpSM.cc:5590
#7 0x005895d6 in HttpSM::perform_cache_write_action
(this=0x7fffe7f7b980) at HttpSM.cc:5540
#8 0x0058ef4d in HttpSM::set_next_state (this=0x7fffe7f7b980) at
HttpSM.cc:7206
#9 0x0058e0be in HttpSM::call_transact_and_set_next_state
(this=0x7fffe7f7b980, f=0) at HttpSM.cc:6962
#10 0x0057bedf in HttpSM::handle_api_return (this=0x7fffe7f7b980) at
HttpSM.cc:1531
#11 0x005944ca in HttpSM::do_api_callout (this=0x7fffe7f7b980) at
HttpSM.cc:452
#12 0x0057cf73 in HttpSM::state_read_server_response_header
(this=0x7fffe7f7b980, event=100, data=0x7fffe0015c78) at HttpSM.cc:1878
#13 0x0057f536 in HttpSM::main_handler (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at HttpSM.cc:2565
#14 0x004f55a6 in Continuation::handleEvent (this=0x7fffe7f7b980,
event=100, data=0x7fffe0015c78) at ../iocore/eventsystem/I_Continuation.h:146
#15 0x006ead77 in read_signal_and_update (event=100,
vc=0x7fffe0015b60) at UnixNetVConnection.cc:137
#16 0x006eb5a7 in read_from_net (nh=0x737cea30,
vc=0x7fffe0015b60, thread=0x737cb010) at UnixNetVConnection.cc:320
#17 0x006ed221 in UnixNetVConnection::net_read_io
(this=0x7fffe0015b60, nh=0x737cea30, lthread=0x737cb010) at
UnixNetVConnection.cc:846
#18 0x006e4dd1 in NetHandler::mainNetEvent (this=0x737cea30,
event=5, e=0x1089e80) at UnixNet.cc:399
#19 0x004f55a6 in Continuation::handleEvent (this=0x737cea30,
event=5, data=0x1089e80) at ../iocore/eventsystem/I_Continuation.h:146
#20 0x0070bace in EThread::process_event (this=0x737cb010,
e=0x1089e80, calling_code=5) at UnixEThread.cc:144
#21 0x0070bfd8 in EThread::execute (this=0x737cb010) at
UnixEThread.cc:268
#22 0x00526644 in main (argv=0x7fffe368) 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
