[jira] [Commented] (TS-1728) Need a way to assign storage entries to volumes
[ https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025227#comment-14025227 ] ASF subversion and git services commented on TS-1728: - Commit a8938835a0c62545f471fe79b256ff7c11ea2224 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a893883 ] Fix indentation from TS-1728 > Need a way to assign storage entries to volumes > --- > > Key: TS-1728 > URL: https://issues.apache.org/jira/browse/TS-1728 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: Jan van Doorn >Assignee: Phil Sorber >Priority: Minor > Fix For: 3.3.4 > > Attachments: vol.patch > > > See http://www.knutsel.com/vol/compare/ for a write up and some test results > on this. We are proposing a simple way to hard link storage.config entries to > volume.config and thus hosting.config entries. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[
https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025362#comment-14025362
]
Leif Hedstrom commented on TS-2632:
---
[~tufang14] Can you try the following patch please?
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index 858499f..812f5d2 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -4035,8 +4035,10 @@ HttpSM::parse_range_and_compare(MIMEField *field,
int64_t content_length)
ink_assert(field != NULL && t_state.range_setup == HttpTransact::RANGE_NONE
&& t_state.ranges == NULL);
- if (content_length <= 0)
+ if (content_length <= 0) {
return;
+ }
+ // ToDo: Can this really happen?
if (content_length == INT64_MAX) {
t_state.range_setup = HttpTransact::RANGE_NOT_HANDLED;
return;
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 08f4146..9ba5186 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -1848,7 +1848,9 @@ HttpTransact::OSDNSLookup(State* s)
StartAccessControl(s);// If skip_dns is enabled and no ip based
rules in cache.config and parent.config
// Access Control is called after DNS response
} else {
- if ((s->cache_info.action == CACHE_DO_NO_ACTION) &&
s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE)) {
+ if ((s->cache_info.action == CACHE_DO_NO_ACTION) &&
+ (((s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE) &&
!s->txn_conf->cache_range_write) ||
+s->range_setup == RANGE_NOT_SATISFIABLE || s->range_setup ==
RANGE_NOT_HANDLED))) {
TRANSACT_RETURN(SM_ACTION_API_OS_DNS, HandleCacheOpenReadMiss);
} else if (s->cache_lookup_result == HttpTransact::CACHE_LOOKUP_SKIPPED)
{
TRANSACT_RETURN(SM_ACTION_API_OS_DNS, LookupSkipOpenServer);
@@ -3085,7 +3087,8 @@ HttpTransact::HandleCacheOpenReadMiss(State* s)
// We must, however, not cache the responses to these requests.
if (does_method_require_cache_copy_deletion(s->method) &&
s->api_req_cacheable == false) {
s->cache_info.action = CACHE_DO_NO_ACTION;
- } else if (s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE)) {
+ } else if ((s->hdr_info.client_request.presence(MIME_PRESENCE_RANGE) &&
!s->txn_conf->cache_range_write) ||
+ s->range_setup == RANGE_NOT_SATISFIABLE || s->range_setup ==
RANGE_NOT_HANDLED) {
s->cache_info.action = CACHE_DO_NO_ACTION;
} else {
s->cache_info.action = CACHE_PREPARE_TO_WRITE;
{code}
This restores the code such that the new behavior (triggered on the presence of
a Range: header) only happens if the new configuration is not enabled. When
enabled, the code should be identical in behavior as 4.2.x.
Please let me know if this looks good, and that it solves the problem you are
seeing.
> Range request will always lock object in cache, even thought it's rarely
> cacheable
> --
>
> Key: TS-2632
> URL: https://issues.apache.org/jira/browse/TS-2632
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
> Attachments: range.diff
>
>
> Right now, if a client sends a Range: request, we still lock the URL in the
> cache, under the assumption that it will be written to. Since we don't
> support partial objects, in almost all cases, we'll not write the object and
> therefore release the object.
> I suggest we change this such that we never try to write lock a URL in the
> presence of a Range: header in the client request. This will allow other
> requests to go to origin faster, and better yet, it allows a request without
> a Range: header to properly lock the URL for writing. This turns out to be
> important for implementing e.g. "background filling" as a plugin.
> There is one use case where this might be useful; If the origin does not
> respond with a 206 (partial object), we can now cache the full object.
> However, this is a pretty rare case, and for someone to support this, all you
> have to do is to remove the Range: header on the request.
> I'm opening up this bug right now for discussion, if anyone have any concerns
> about this change, please let me know. It is an "incompatible" change,
> without configuration options, but that should be ok for the v5.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2881) Redirection handling broken
[ https://issues.apache.org/jira/browse/TS-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2881: --- Labels: yahoo (was: ) > Redirection handling broken > --- > > Key: TS-2881 > URL: https://issues.apache.org/jira/browse/TS-2881 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: yahoo > Fix For: 5.0.0 > > Attachments: ts2881.diff > > > Redirection handling is broken in master. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2881) Redirection handling broken
[ https://issues.apache.org/jira/browse/TS-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025445#comment-14025445 ] ASF subversion and git services commented on TS-2881: - Commit a4b0796325f729c04e880a25c7ae219a77ad5c11 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a4b0796 ] TS-2881: Redirection handling broken > Redirection handling broken > --- > > Key: TS-2881 > URL: https://issues.apache.org/jira/browse/TS-2881 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: yahoo > Fix For: 5.0.0 > > Attachments: ts2881.diff > > > Redirection handling is broken in master. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2881) Redirection handling broken
[ https://issues.apache.org/jira/browse/TS-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025450#comment-14025450 ] ASF subversion and git services commented on TS-2881: - Commit 04d883ed5d92aa3e19ee8f704e0cef1ab36935ad in trafficserver's branch refs/heads/5.0.x from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=04d883e ] TS-2881: Redirection handling broken > Redirection handling broken > --- > > Key: TS-2881 > URL: https://issues.apache.org/jira/browse/TS-2881 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: yahoo > Fix For: 5.0.0 > > Attachments: ts2881.diff > > > Redirection handling is broken in master. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2632. --- Resolution: Fixed Closing again, I'm hoping this works (it works in my tests). > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025716#comment-14025716 ] ASF subversion and git services commented on TS-2632: - Commit dda3209afae73ecd3e5cd9d53d11f2dba528cac6 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dda3209 ] TS-2632 Fixes to check the new configs properly > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025725#comment-14025725 ] ASF subversion and git services commented on TS-2632: - Commit 88deda79dc3e8408e50af4771a894d3af2a741fa in trafficserver's branch refs/heads/5.0.x from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=88deda7 ] TS-2632 Fixes to check the new configs properly > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2883) core dump in SpdyNV::SpdyNV
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025865#comment-14025865
]
Sudheer Vinukonda commented on TS-2883:
---
Don't see this core dump with commits before June 3, 2014.
> core dump in SpdyNV::SpdyNV
> ---
>
> Key: TS-2883
> URL: https://issues.apache.org/jira/browse/TS-2883
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
>
> {code}
> (gdb) bt
> #0 0x0038818328e5 in raise () from /lib64/libc.so.6
> #1 0x0038818340c5 in abort () from /lib64/libc.so.6
> #2 0x0038818707f7 in __libc_message () from /lib64/libc.so.6
> #3 0x003881876126 in malloc_printerr () from /lib64/libc.so.6
> #4 0x003881879ba4 in _int_malloc () from /lib64/libc.so.6
> #5 0x00388187a951 in malloc () from /lib64/libc.so.6
> #6 0x005f046d in SpdyNV::SpdyNV (this=0x2b2368301a00,
> fetch_sm=0x2b258e8df7e0) at SpdyCommon.cc:93
> #7 0x005ef300 in spdy_process_fetch_header (this=0x2b254c7201b0,
> event=-2, edata=0x2b258e8df7e0) at SpdyClientSession.cc:359
> #8 spdy_process_fetch (this=0x2b254c7201b0, event=-2, edata=0x2b258e8df7e0)
> at SpdyClientSession.cc:321
> #9 SpdyClientSession::state_session_readwrite (this=0x2b254c7201b0,
> event=-2, edata=0x2b258e8df7e0) at SpdyClientSession.cc:251
> #10 0x004a42fa in handleEvent (this=0x2b258e8df7e0, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #11 FetchSM::InvokePluginExt (this=0x2b258e8df7e0, error_event=0) at
> FetchSM.cc:233
> #12 0x004a47d7 in FetchSM::process_fetch_read (this=0x2b258e8df7e0,
> event=) at FetchSM.cc:400
> #13 0x004a498b in FetchSM::fetch_handler (this=0x2b258e8df7e0,
> event=100, edata=0x2b253d6550a8) at FetchSM.cc:449
> #14 0x004dd2e5 in PluginVC::process_read_side (this=0x2b253d654fb0,
> other_side_call=true) at PluginVC.cc:671
> #15 0x004ddc3a in PluginVC::process_write_side (this=0x2b253d655190,
> other_side_call=false) at PluginVC.cc:567
> #16 0x004df405 in PluginVC::main_handler (this=0x2b253d655190,
> event=, data=0x2b25cc556370) at PluginVC.cc:212
> #17 0x0073252f in handleEvent (this=0x2b2361df9010, e=0x2b25cc556370,
> calling_code=1) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2b2361df9010, e=0x2b25cc556370,
> calling_code=1) at UnixEThread.cc:145
> #19 0x0073305b in EThread::execute (this=0x2b2361df9010) at
> UnixEThread.cc:196
> #20 0x007318da in spawn_thread_internal (a=0x2ffbfd0) at Thread.cc:88
> #21 0x2b235fc7e851 in start_thread () from /lib64/libpthread.so.0
> #22 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2882) Core dump inside spdylay library
[
https://issues.apache.org/jira/browse/TS-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025866#comment-14025866
]
Sudheer Vinukonda commented on TS-2882:
---
Don't see this core dump with commits before June 3, 2014.
> Core dump inside spdylay library
>
>
> Key: TS-2882
> URL: https://issues.apache.org/jira/browse/TS-2882
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
>
> {code}
> (gdb) bt
> #0 0x0038818328e5 in raise () from /lib64/libc.so.6
> #1 0x0038818340c5 in abort () from /lib64/libc.so.6
> #2 0x0038818707f7 in __libc_message () from /lib64/libc.so.6
> #3 0x003881876126 in malloc_printerr () from /lib64/libc.so.6
> #4 0x00739e19 in spdylay_outbound_item_free (item=0x2b7e2000b510) at
> spdylay_outbound_item.c:81
> #5 0x00737428 in spdylay_session_send (session=0x2b7ed59ae4f0) at
> spdylay_session.c:1538
> #6 0x005ef26c in spdy_process_write (this=0x2b7f24597800, event=101,
> edata=0x2b7e94194cf0) at SpdyClientSession.cc:291
> #7 SpdyClientSession::state_session_readwrite (this=0x2b7f24597800,
> event=101, edata=0x2b7e94194cf0) at SpdyClientSession.cc:248
> #8 0x0070d8bb in handleEvent (event=,
> vc=0x2b7e94194b80) at ../../iocore/eventsystem/I_Continuation.h:146
> #9 write_signal_and_update (event=, vc=0x2b7e94194b80)
> at UnixNetVConnection.cc:153
> #10 0x0070fe93 in write_to_net_io (nh=0x2b7d39f6dbc0,
> vc=0x2b7e94194b80, thread=0x2b7d39f6a010) at UnixNetVConnection.cc:421
> #11 0x00705c43 in NetHandler::mainNetEvent (this=0x2b7d39f6dbc0,
> event=, e=) at UnixNet.cc:415
> #12 0x0073252f in handleEvent (this=0x2b7d39f6a010, e=0x1e332f0,
> calling_code=5) at I_Continuation.h:146
> #13 EThread::process_event (this=0x2b7d39f6a010, e=0x1e332f0, calling_code=5)
> at UnixEThread.cc:145
> #14 0x00732ed3 in EThread::execute (this=0x2b7d39f6a010) at
> UnixEThread.cc:269
> #15 0x007318da in spawn_thread_internal (a=0x22a0a60) at Thread.cc:88
> #16 0x2b7c97400851 in start_thread () from /lib64/libpthread.so.0
> #17 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) quit
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025863#comment-14025863
]
Sudheer Vinukonda commented on TS-2878:
---
We are testing with the version of master with commits before June 3, 2014,
PLUS with TS-2766 reverted. Will update the progress further.
> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb)
> #0 0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
> buf_start=0x2ad0ccddf6fc
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR;
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
> Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2745
> #2 0x0064422c in mime_hdr_print (mh=,
> buf_start=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2623
> #3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
> hdr=0x2ad0c12eb098,
> buf=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096,
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4 0x0059c676 in print (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5 HttpSM::write_header_into_buffer (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6 0x0059e9bb in HttpSM::setup_server_send_request
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1508
> #8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=,
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=,
> opt=0x2acf1cd09e00,
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0,
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler
> (contp=0x2ad03008d930, event=TS_EVENT_HTTP_OS_DNS, edata=0x2acf6e0e7dc0) at
> yca_plugin.cpp:961
> #27 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #28 0x00
[jira] [Commented] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025894#comment-14025894
]
Brian Geffon commented on TS-2878:
--
Why would you revert TS-2766? it fixed a known bug.
> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb)
> #0 0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
> buf_start=0x2ad0ccddf6fc
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR;
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
> Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2745
> #2 0x0064422c in mime_hdr_print (mh=,
> buf_start=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2623
> #3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
> hdr=0x2ad0c12eb098,
> buf=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096,
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4 0x0059c676 in print (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5 HttpSM::write_header_into_buffer (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6 0x0059e9bb in HttpSM::setup_server_send_request
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1508
> #8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=,
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=,
> opt=0x2acf1cd09e00,
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0,
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler
> (contp=0x2ad03008d930, event=TS_EVENT_HTTP_OS_DNS, edata=0x2acf6e0e7dc0) at
> yca_plugin.cpp:961
> #27 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #28 0x005a9fd2 in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
> HttpSM.cc:6826
> #29 0x00593
[jira] [Comment Edited] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025894#comment-14025894
]
Brian Geffon edited comment on TS-2878 at 6/9/14 11:04 PM:
---
Why would you revert TS-2766? it fixed a known bug. TS-2766 is a simple patch,
i can guarantee it isn't the cause of your crashes. Also, why did you guys pick
Jun 30th?
was (Author: briang):
Why would you revert TS-2766? it fixed a known bug.
> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb)
> #0 0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
> buf_start=0x2ad0ccddf6fc
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR;
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
> Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2745
> #2 0x0064422c in mime_hdr_print (mh=,
> buf_start=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2623
> #3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
> hdr=0x2ad0c12eb098,
> buf=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096,
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4 0x0059c676 in print (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5 HttpSM::write_header_into_buffer (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6 0x0059e9bb in HttpSM::setup_server_send_request
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1508
> #8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=,
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=,
> opt=0x2acf1cd09e00,
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0,
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3 in yca_auth_plugin_local_handler
> (contp=0x2ad03008d930, event=TS_EVENT_HTTP_OS_DNS, edata=0x2acf6e0e7dc0) at
> yc
[jira] [Comment Edited] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025894#comment-14025894
]
Brian Geffon edited comment on TS-2878 at 6/9/14 11:04 PM:
---
Why would you revert TS-2766? it fixed a known bug. TS-2766 is a simple patch,
i can guarantee it isn't the cause of your crashes. Also, why did you guys pick
Jun 3rd?
was (Author: briang):
Why would you revert TS-2766? it fixed a known bug. TS-2766 is a simple patch,
i can guarantee it isn't the cause of your crashes. Also, why did you guys pick
Jun 30th?
> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb)
> #0 0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
> buf_start=0x2ad0ccddf6fc
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR;
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
> Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2745
> #2 0x0064422c in mime_hdr_print (mh=,
> buf_start=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2623
> #3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
> hdr=0x2ad0c12eb098,
> buf=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096,
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4 0x0059c676 in print (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5 HttpSM::write_header_into_buffer (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6 0x0059e9bb in HttpSM::setup_server_send_request
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1508
> #8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=,
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=,
> opt=0x2acf1cd09e00,
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #25 0x2acf13dd3492 in append_own_yca_certificate (txnp=0x2acf6e0e7dc0,
> contp=, data=) at yca_plugin.cpp:266
> #26 0x2acf13dd3ad3
[jira] [Commented] (TS-2878) Core dump in mime_field_print
[
https://issues.apache.org/jira/browse/TS-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025906#comment-14025906
]
Sudheer Vinukonda commented on TS-2878:
---
Hey, [~briang] - The changes made in TS-2766 seem to be in a related area and
in our tests, we don't recall seeing this particular core dump before TS-2766.
However, at the same time, that was a little while ago, and we are not
completely certain if this core dump is a side affect of TS-2766 or some other
change.
Jun 3rd was when we had one of our last reasonably "stable" 5.0 versions, which
only had mime_field_print core dump and not the other weird cores (TS-2882,
TS-2883). So, we are just testing those particular versions, without TS-2766,
to isolate the issue further. Will keep you posted.
> Core dump in mime_field_print
> -
>
> Key: TS-2878
> URL: https://issues.apache.org/jira/browse/TS-2878
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.0
>Reporter: Sudheer Vinukonda
>
> Found a new core dump on one of our production hosts with the latest master.
> {code}
> (gdb)
> #0 0x00366a489932 in memcpy () from /lib64/libc.so.6
> #1 0x006440ec in mime_field_print (field=0x2ad0c12eb398,
> buf_start=0x2ad0ccddf6fc
> "b=4&d=N8yEv7ppYEIU22_VquwWHph5uWBFcIT0fZmeGg--&s=l0&i=jE4n8cjO._g4wBfgSzBR;
> F=a=d7RTbXcMvSscJ6tvYRkm3uidpW7e4pvmEH8Vl9bGaVDpBGZ6bL4NJuiQDJLIQ1MsxDYfXJc-&b=pfgj;
> Y=v=1&n=3kntebmsf6jf7&l=43m0h3.2705544@"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2745
> #2 0x0064422c in mime_hdr_print (mh=,
> buf_start=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., buf_length=4096,
> buf_index_inout=0x2acf1cd0883c, buf_chars_to_skip_inout=0x2acf1cd08838) at
> MIME.cc:2623
> #3 0x00639b52 in http_hdr_print (heap=0x2ad0c12eb010,
> hdr=0x2ad0c12eb098,
> buf=0x2ad0ccddf000 "POST
> /w/ygo-mail/msgedit.bp?ci=1&.ts=1401981151&_httpHost=m.yahoo.com&.intl=MX&.lang=es-mx
> HTTP/1.1\r\nHost: m.yahoo.com\r\nAccept-Charset: utf-8, iso-8859-1,
> iso-8859-2, iso-10646, us-ascii, *\r\nAccept-La"..., bufsize=4096,
> bufindex=0x2acf1cd0883c, dumpoffset=0x2acf1cd08838) at HTTP.cc:555
> #4 0x0059c676 in print (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at ../../proxy/hdrs/HTTP.h:897
> #5 HttpSM::write_header_into_buffer (this=,
> h=0x2acf6e0e8548, b=0x2ad0240b56d0) at HttpSM.cc:5457
> #6 0x0059e9bb in HttpSM::setup_server_send_request
> (this=0x2acf6e0e7dc0) at HttpSM.cc:5576
> #7 0x005ac1f5 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1508
> #8 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #9 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #10 0x004c99cc in TSHttpTxnReenable (txnp=0x2acf6e0e7dc0,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5543
> #11 0x2acf12d247fc in http_hook (contp=,
> event=, edata=0x2acf6e0e7dc0) at INKPluginInit.cc:177
> #12 0x005a4416 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=, data=) at HttpSM.cc:1362
> #13 0x005a618b in HttpSM::state_http_server_open
> (this=0x2acf6e0e7dc0, event=, data=0x2ad0b88802d0) at
> HttpSM.cc:1643
> #14 0x005a70e8 in HttpSM::main_handler (this=0x2acf6e0e7dc0,
> event=200, data=0x2ad0b88802d0) at HttpSM.cc:2501
> #15 0x0070f96d in handleEvent (this=0x2ad0b88802d0, t= optimized out>, fd=-1) at ../../iocore/eventsystem/I_Continuation.h:146
> #16 UnixNetVConnection::connectUp (this=0x2ad0b88802d0, t= out>, fd=-1) at UnixNetVConnection.cc:1159
> #17 0x0070d01f in UnixNetProcessor::connect_re_internal (this= optimized out>, cont=, target=,
> opt=0x2acf1cd09e00,
> servername=0x2ad0b88804fc "\002") at UnixNetProcessor.cc:255
> #18 0x005a568b in connect_re (this=0x2acf6e0e7dc0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:87
> #19 HttpSM::do_http_server_open (this=0x2acf6e0e7dc0, raw= out>) at HttpSM.cc:4646
> #20 0x005aa2bd in HttpSM::set_next_state (this=0x2acf6e0e7dc0) at
> HttpSM.cc:6975
> #21 0x005ac132 in HttpSM::handle_api_return (this=0x2acf6e0e7dc0) at
> HttpSM.cc:1505
> #22 0x005a45b0 in HttpSM::state_api_callout (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1437
> #23 0x005a76aa in HttpSM::state_api_callback (this=0x2acf6e0e7dc0,
> event=6, data=0x0) at HttpSM.cc:1255
> #24 0x004c99cc in TSHttpTxnReenable (txnp=0
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026040#comment-14026040 ] Qiang Li commented on TS-2632: -- Leif Hedstrom it works well now:-) > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
