[jira] [Updated] (TS-4989) Don't add Age: header to requests not served from cache
[ https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-4989: - Labels: yahoo (was: ) > Don't add Age: header to requests not served from cache > --- > > Key: TS-4989 > URL: https://issues.apache.org/jira/browse/TS-4989 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: David Carlin > Labels: yahoo > > You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a > request - for requests not served from cache. Causes confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4989) Don't add Age: header to requests not served from cache
David Carlin created TS-4989: Summary: Don't add Age: header to requests not served from cache Key: TS-4989 URL: https://issues.apache.org/jira/browse/TS-4989 Project: Traffic Server Issue Type: Bug Components: Core Reporter: David Carlin You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a request - for requests not served from cache. Causes confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4434) Can't start ATS when v6 enabled but not configured on interface
[
https://issues.apache.org/jira/browse/TS-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15453240#comment-15453240
]
David Carlin commented on TS-4434:
--
I only seem to have this problem when IPv6 is explicitly disabled:
{{/etc/modprobe.conf:options ipv6 disable=1}}
> Can't start ATS when v6 enabled but not configured on interface
> ---
>
> Key: TS-4434
> URL: https://issues.apache.org/jira/browse/TS-4434
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: David Carlin
>Assignee: Steven Feltner
> Fix For: 7.0.0
>
>
> FYI since there was a discussion at summit about v6 being enabled by default.
> You can't start ATS when v6 enabled but not configured on interface -
> observed in ATS 5.3
> {code}
> [May 10 16:50:10.995] {0x7f3b579a47e0} NOTE: updated diags config
> [May 10 16:50:10.997] Manager {0x7f3b579a47e0} NOTE: [ClusterCom::ClusterCom]
> Node running on OS: 'Linux' Release: '2.6.32-220.23.1.el6.20120'
> [May 10 16:50:10.998] Manager {0x7f3b579a47e0} ERROR: [bindProxyPort] Unable
> to create socket : Address family not supported by protocol{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4434) Can't start ATS when v6 enabled but not configured on interface
David Carlin created TS-4434:
Summary: Can't start ATS when v6 enabled but not configured on
interface
Key: TS-4434
URL: https://issues.apache.org/jira/browse/TS-4434
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: David Carlin
FYI since there was a discussion at summit about v6 being enabled by default.
You can't start ATS when v6 enabled but not configured on interface - observed
in ATS 5.3
{code}
[May 10 16:50:10.995] {0x7f3b579a47e0} NOTE: updated diags config
[May 10 16:50:10.997] Manager {0x7f3b579a47e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-220.23.1.el6.20120'
[May 10 16:50:10.998] Manager {0x7f3b579a47e0} ERROR: [bindProxyPort] Unable to
create socket : Address family not supported by protocol{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4009) stale_while_revalidate crash
[
https://issues.apache.org/jira/browse/TS-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-4009:
-
Labels: regression yahoo (was: regression)
> stale_while_revalidate crash
>
>
> Key: TS-4009
> URL: https://issues.apache.org/jira/browse/TS-4009
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.0.0
>Reporter: Christoph Keller
>Assignee: Leif Hedstrom
> Labels: regression, yahoo
> Fix For: 6.1.0
>
>
> Since 6.0 stale_while_revalidate-plugin crashes after serving a stale
> document while trying to get the new one. Can reproduce this issue with 6.0.x
> and master branch using the provided testserver. 5.3.x works fine. Doesn't
> look like that issue is up to some changes in the plugin-code so i guess it's
> an issue in the core code.
> {quote}
> #0 0x2b75ae4625d7 in raise () from /lib64/libc.so.6
> #1 0x2b75ae463cc8 in abort () from /lib64/libc.so.6
> #2 0x2b75abdfd29d in ink_die_die_die () at ink_error.cc:43
> #3 0x2b75abdfd356 in ink_fatal_va (fmt=0x2b75abe0e088 "%s:%d: failed
> assert `%s`", ap=0x2b75c0804a48) at ink_error.cc:65
> #4 0x2b75abdfd3f5 in ink_fatal (message_format=0x2b75abe0e088 "%s:%d:
> failed assert `%s`") at ink_error.cc:73
> #5 0x2b75abdfb016 in _ink_assert (expression=0x7b6e00 "((INKContInternal
> *)contp)->mutex", file=0x7b5dc5 "InkAPI.cc", line=6302) at ink_assert.cc:37
> #6 0x0051a5e2 in _TSReleaseAssert (text=0x7b6e00 "((INKContInternal
> *)contp)->mutex", file=0x7b5dc5 "InkAPI.cc", line=6302) at InkAPI.cc:407
> #7 0x00528563 in TSVConnRead (connp=0x2b75d928, contp=0x28e6d60,
> bufp=0x2b75b801d5b0, nbytes=9223372036854775807) at InkAPI.cc:6302
> #8 0x2b75b65d1795 in fetch_resource (cont=0x28e6dd0,
> event=TS_EVENT_IMMEDIATE, edata=0x2825ba0) at stale_while_revalidate.c:449
> #9 0x0051b4a7 in INKContInternal::handle_event (this=0x28e6dd0,
> event=1, edata=0x2825ba0) at InkAPI.cc:1005
> #10 0x00506e34 in Continuation::handleEvent (this=0x28e6dd0, event=1,
> data=0x2825ba0) at ../iocore/eventsystem/I_Continuation.h:146
> #11 0x007ac72e in EThread::process_event (this=0x2b75c0503010,
> e=0x2825ba0, calling_code=1) at UnixEThread.cc:128
> #12 0x007ac990 in EThread::execute (this=0x2b75c0503010) at
> UnixEThread.cc:179
> #13 0x007abc91 in spawn_thread_internal (a=0x2a7d460) at Thread.cc:86
> #14 0x2b75ad48cdf5 in start_thread () from /lib64/libpthread.so.0
> #15 0x2b75ae5231ad in clone () from /lib64/libc.so.6
> {quote}
> EDIT: I guess i just found it. I don't know why but NULL seems to be a
> problem right here
> "consume_cont = TSContCreate(consume_resource, NULL);" in fetch_resource
> In case i create a new TSMutex and pass it to this call it seems to work.
> Trying to make a patch for that now.
> I guess it is broken due to these changes:
> https://issues.apache.org/jira/browse/TS-3569
> https://github.com/apache/trafficserver/commit/a36c416786c79c643cd11fd332274365bc893bb6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4069) proxy.config.diags.show_location doesn't work for plugins
David Carlin created TS-4069: Summary: proxy.config.diags.show_location doesn't work for plugins Key: TS-4069 URL: https://issues.apache.org/jira/browse/TS-4069 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: David Carlin enabling proxy.config.diags.show_location doesn't provide any additional debug info for plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4069) proxy.config.diags.show_location doesn't work for plugins
[ https://issues.apache.org/jira/browse/TS-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-4069: - Affects Version/s: 5.3.0 > proxy.config.diags.show_location doesn't work for plugins > - > > Key: TS-4069 > URL: https://issues.apache.org/jira/browse/TS-4069 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 5.3.0 >Reporter: David Carlin > Labels: 5.3.x, yahoo > > enabling proxy.config.diags.show_location doesn't provide any additional > debug info for plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4069) proxy.config.diags.show_location doesn't work for plugins
[ https://issues.apache.org/jira/browse/TS-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-4069: - Labels: 5.3.x yahoo (was: ) > proxy.config.diags.show_location doesn't work for plugins > - > > Key: TS-4069 > URL: https://issues.apache.org/jira/browse/TS-4069 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: David Carlin > Labels: 5.3.x, yahoo > > enabling proxy.config.diags.show_location doesn't provide any additional > debug info for plugins. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3963) Response headers are not completely transferred
[ https://issues.apache.org/jira/browse/TS-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3963: - Labels: yahoo (was: ) > Response headers are not completely transferred > --- > > Key: TS-3963 > URL: https://issues.apache.org/jira/browse/TS-3963 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masakazu Kitajo > Labels: yahoo > Fix For: 6.1.0 > > Attachments: ts-3963.diff > > > TS loses one response header (one pair of header name and its value) per > requiring a CONTINUATION frame. > You can see the behavior by sending many response headers from an origin > server. It happens when the total size of the headers is over 4KB. > It seems that field_iter in http2_write_header_fragment() incorrectly steps > forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3974) Improvements to debug log
[
https://issues.apache.org/jira/browse/TS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3974:
-
Issue Type: Improvement (was: Bug)
> Improvements to debug log
> -
>
> Key: TS-3974
> URL: https://issues.apache.org/jira/browse/TS-3974
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: David Carlin
> Labels: yahoo
>
> A couple suggestions to improve the readability of the debug logs.
> # Can the transaction ID be put on every debug log entry, similar to how the
> thread ID is on every debug log entry? Then you could grep for a particular
> transaction ID and only see those messages.
> # Can we get a squid.log field for transaction ID? Then you can go looking
> for it in debug log.
> # Some messages currently have transaction ID inside of square braces, but
> square braces are used elsewhere. For example:
> \\
> {noformat}[Oct 19 15:56:16.140] Server {0x2b3dbf130700} DEBUG: (http)
> [147596] State Transition: SM_ACTION_ORIGIN_SERVER_OPEN ->
> SM_ACTION_SERVER_READ{noformat}
> In the above example 147596 is transaction ID. But look at this:
> \\
> {noformat}[Oct 19 10:29:10.273] Server {0x7ff0c9de08c0} DEBUG:
> (http_cs) [2] session released by sm
> [1]{noformat}
> Square braces notation also used for HTTP2 client session and state machine.
> So please pick something unique for transaction ID.
> # Is it necessary for this http header debug messages to be split across so
> many lines? At a minimum can the header name and header value be on the same
> line? Its hard to read debug log output when there are many clients making
> requests at same time.
> {noformat}
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http)
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) SLOT # 4
> (0x2b8818421188), LIVE
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) [N:
> "Accept-Language", N_LEN: 15, N_IDX: 2,
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) V: "en-ca",
> V_LEN: 5,
> [Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http) NEXTDUP: (nil),
> RAW: 1, RAWLEN: 24, F: 1]
> [Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3974) Improvements to debug log
[
https://issues.apache.org/jira/browse/TS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3974:
-
Labels: yahoo (was: )
> Improvements to debug log
> -
>
> Key: TS-3974
> URL: https://issues.apache.org/jira/browse/TS-3974
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: David Carlin
> Labels: yahoo
>
> A couple suggestions to improve the readability of the debug logs.
> # Can the transaction ID be put on every debug log entry, similar to how the
> thread ID is on every debug log entry? Then you could grep for a particular
> transaction ID and only see those messages.
> # Can we get a squid.log field for transaction ID? Then you can go looking
> for it in debug log.
> # Some messages currently have transaction ID inside of square braces, but
> square braces are used elsewhere. For example:
> \\
> {noformat}[Oct 19 15:56:16.140] Server {0x2b3dbf130700} DEBUG: (http)
> [147596] State Transition: SM_ACTION_ORIGIN_SERVER_OPEN ->
> SM_ACTION_SERVER_READ{noformat}
> In the above example 147596 is transaction ID. But look at this:
> \\
> {noformat}[Oct 19 10:29:10.273] Server {0x7ff0c9de08c0} DEBUG:
> (http_cs) [2] session released by sm
> [1]{noformat}
> Square braces notation also used for HTTP2 client session and state machine.
> So please pick something unique for transaction ID.
> # Is it necessary for this http header debug messages to be split across so
> many lines? At a minimum can the header name and header value be on the same
> line? Its hard to read debug log output when there are many clients making
> requests at same time.
> {noformat}
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http)
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) SLOT # 4
> (0x2b8818421188), LIVE
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) [N:
> "Accept-Language", N_LEN: 15, N_IDX: 2,
> [Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) V: "en-ca",
> V_LEN: 5,
> [Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http) NEXTDUP: (nil),
> RAW: 1, RAWLEN: 24, F: 1]
> [Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3974) Improvements to debug log
David Carlin created TS-3974:
Summary: Improvements to debug log
Key: TS-3974
URL: https://issues.apache.org/jira/browse/TS-3974
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: David Carlin
A couple suggestions to improve the readability of the debug logs.
# Can the transaction ID be put on every debug log entry, similar to how the
thread ID is on every debug log entry? Then you could grep for a particular
transaction ID and only see those messages.
# Can we get a squid.log field for transaction ID? Then you can go looking for
it in debug log.
# Some messages currently have transaction ID inside of square braces, but
square braces are used elsewhere. For example:
\\
{noformat}[Oct 19 15:56:16.140] Server {0x2b3dbf130700} DEBUG: (http) [147596]
State Transition: SM_ACTION_ORIGIN_SERVER_OPEN ->
SM_ACTION_SERVER_READ{noformat}
In the above example 147596 is transaction ID. But look at this:
\\
{noformat}[Oct 19 10:29:10.273] Server {0x7ff0c9de08c0} DEBUG:
(http_cs) [2] session released by sm
[1]{noformat}
Square braces notation also used for HTTP2 client session and state machine.
So please pick something unique for transaction ID.
# Is it necessary for this http header debug messages to be split across so
many lines? At a minimum can the header name and header value be on the same
line? Its hard to read debug log output when there are many clients making
requests at same time.
{noformat}
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http)
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) SLOT # 4
(0x2b8818421188), LIVE
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) [N:
"Accept-Language", N_LEN: 15, N_IDX: 2,
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) V: "en-ca", V_LEN:
5,
[Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http) NEXTDUP: (nil),
RAW: 1, RAWLEN: 24, F: 1]
[Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3974) Improvements to debug log
[
https://issues.apache.org/jira/browse/TS-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3974:
-
Description:
A couple suggestions to improve the readability of the debug logs.
# Can the transaction ID be put on every debug log entry, similar to how the
thread ID is on every debug log entry? Then you could grep for a particular
transaction ID and only see those messages.
# Can we get a squid.log field for transaction ID? Then you can go looking for
it in debug log.
# Some messages currently have transaction ID inside of square braces, but
square braces are used elsewhere. For example:
\\
{noformat}[Oct 19 15:56:16.140] Server {0x2b3dbf130700} DEBUG: (http) [147596]
State Transition: SM_ACTION_ORIGIN_SERVER_OPEN ->
SM_ACTION_SERVER_READ{noformat}
In the above example 147596 is transaction ID. But look at this:
\\
{noformat}[Oct 19 10:29:10.273] Server {0x7ff0c9de08c0} DEBUG:
(http_cs) [2] session released by sm
[1]{noformat}
Square braces notation also used for HTTP2 client session and state machine.
So please pick something unique for transaction ID.
# Is it necessary for http header debug messages to be split across so many
lines? At a minimum can the header name and header value be on the same line?
Its hard to read debug log output when there are many clients making requests
at same time.
{noformat}
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http)
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) SLOT # 4
(0x2b8818421188), LIVE
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) [N:
"Accept-Language", N_LEN: 15, N_IDX: 2,
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) V: "en-ca", V_LEN:
5,
[Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http) NEXTDUP: (nil),
RAW: 1, RAWLEN: 24, F: 1]
[Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http)
{noformat}
was:
A couple suggestions to improve the readability of the debug logs.
# Can the transaction ID be put on every debug log entry, similar to how the
thread ID is on every debug log entry? Then you could grep for a particular
transaction ID and only see those messages.
# Can we get a squid.log field for transaction ID? Then you can go looking for
it in debug log.
# Some messages currently have transaction ID inside of square braces, but
square braces are used elsewhere. For example:
\\
{noformat}[Oct 19 15:56:16.140] Server {0x2b3dbf130700} DEBUG: (http) [147596]
State Transition: SM_ACTION_ORIGIN_SERVER_OPEN ->
SM_ACTION_SERVER_READ{noformat}
In the above example 147596 is transaction ID. But look at this:
\\
{noformat}[Oct 19 10:29:10.273] Server {0x7ff0c9de08c0} DEBUG:
(http_cs) [2] session released by sm
[1]{noformat}
Square braces notation also used for HTTP2 client session and state machine.
So please pick something unique for transaction ID.
# Is it necessary for this http header debug messages to be split across so
many lines? At a minimum can the header name and header value be on the same
line? Its hard to read debug log output when there are many clients making
requests at same time.
{noformat}
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http)
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) SLOT # 4
(0x2b8818421188), LIVE
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) [N:
"Accept-Language", N_LEN: 15, N_IDX: 2,
[Oct 19 20:18:44.744] Server {0x2b871b635700} DEBUG: (http) V: "en-ca", V_LEN:
5,
[Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http) NEXTDUP: (nil),
RAW: 1, RAWLEN: 24, F: 1]
[Oct 19 20:18:44.745] Server {0x2b871b635700} DEBUG: (http)
{noformat}
> Improvements to debug log
> -
>
> Key: TS-3974
> URL: https://issues.apache.org/jira/browse/TS-3974
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: David Carlin
> Labels: yahoo
>
> A couple suggestions to improve the readability of the debug logs.
> # Can the transaction ID be put on every debug log entry, similar to how the
> thread ID is on every debug log entry? Then you could grep for a particular
> transaction ID and only see those messages.
> # Can we get a squid.log field for transaction ID? Then you can go looking
> for it in debug log.
> # Some messages currently have transaction ID inside of square braces, but
> square braces are used elsewhere. For example:
> \\
> {noformat}[Oct 19 15:56:16.140] Server {0x2b3dbf130700} DEBUG: (http)
> [147596] State Transition: SM_ACTION_ORIGIN_SERVER_OPEN ->
> SM_ACTION_SERVER_READ{noformat}
> In the above example 147596 is transaction ID. But look at this:
> \\
> {noformat}[Oct 19 10:29:10.273] Server {0x7ff0c9de08c0} DEBUG:
> (http_cs) [2] session released by sm
> [1]{noformat}
> Square braces notation also used for HTTP2 client session and
[jira] [Commented] (TS-2523) automatically max out the listen backlog
[
https://issues.apache.org/jira/browse/TS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14956229#comment-14956229
]
David Carlin commented on TS-2523:
--
A new ATS user ran into this issue during load testing while evaluating ATS;
it would be nice if -1 existed and was the default
> automatically max out the listen backlog
>
>
> Key: TS-2523
> URL: https://issues.apache.org/jira/browse/TS-2523
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Network
>Reporter: James Peach
> Labels: incompatible, yahoo
> Fix For: sometime
>
>
> Rather than choosing the right value for {{proxy.config.net.listen_backlog}},
> we should support a -1 default. This would max out the listen backlog on
> systems where we know how to find that, and set it to {{SOMAXCON}} everywhere
> else.
> On Linux, the max backlog is 65535 (unsigned short), and the kernel will clip
> that to {{/proc/sys/net/core/somaxconn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2523) automatically max out the listen backlog
[
https://issues.apache.org/jira/browse/TS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2523:
-
Labels: incompatible yahoo (was: incompatible)
> automatically max out the listen backlog
>
>
> Key: TS-2523
> URL: https://issues.apache.org/jira/browse/TS-2523
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Network
>Reporter: James Peach
> Labels: incompatible, yahoo
> Fix For: sometime
>
>
> Rather than choosing the right value for {{proxy.config.net.listen_backlog}},
> we should support a -1 default. This would max out the listen backlog on
> systems where we know how to find that, and set it to {{SOMAXCON}} everywhere
> else.
> On Linux, the max backlog is 65535 (unsigned short), and the kernel will clip
> that to {{/proc/sys/net/core/somaxconn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3952) SSLNetVConnection::free crashes when "nh" is not initialized
[
https://issues.apache.org/jira/browse/TS-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3952:
-
Labels: yahoo (was: )
> SSLNetVConnection::free crashes when "nh" is not initialized
>
>
> Key: TS-3952
> URL: https://issues.apache.org/jira/browse/TS-3952
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: Sudheer Vinukonda
> Labels: yahoo
>
> On failure to making a connection, the *nh* is not init'ed in netVC and
> ::free crashes on a null pointer.
>
> Below's the backtrace:
> {code}
> (gdb) bt
> #0 0x006da394 in Queue UnixNetVConnection::Link_read_ready_link>::remove (this=0x38,
> e=0x2b46c5b97e10) at ../../lib/ts/List.h:251
> #1 0x0072bb47 in SSLNetVConnection::free (this=0x2b46c5b97e10,
> t=0x2b456810) at SSLNetVConnection.cc:630
> #2 0x007430c9 in UnixNetVConnection::connectUp (this=0x2b46c5b97e10,
> t=0x2b456810, fd=-1) at UnixNetVConnection.cc:1269
> #3 0x0073dbf8 in UnixNetProcessor::connect_re_internal
> (this=0x1029960, cont=0x2b4a5ca1c5c0, target=0x2b4a5ca1c870,
> opt=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> UnixNetProcessor.cc:255
> #4 0x00521d23 in NetProcessor::connect_re (this=0x1029960,
> cont=0x2b4a5ca1c5c0, addr=0x2b4a5ca1c870, opts=0x2b456bc36de0,
> servername=0x2b476c6c9530 "md2liveorigin02.atlas.cdn.md2.yahoo.com") at
> ../iocore/net/P_UnixNetProcessor.h:87
> #5 0x005db17e in HttpSM::do_http_server_open (this=0x2b4a5ca1c5c0,
> raw=false) at HttpSM.cc:4759
> #6 0x005e2d4d in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7128
> #7 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #8 0x005d2afc in HttpSM::state_cache_open_write (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2415
> #9 0x005d31cd in HttpSM::main_handler (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at HttpSM.cc:2522
> #10 0x004f8d4c in Continuation::handleEvent (this=0x2b4a5ca1c5c0,
> event=1109, data=0xb04f) at
> ../iocore/eventsystem/I_Continuation.h:146
> #11 0x005bef39 in HttpCacheSM::open_write (this=0x2b4a5ca1d7d0,
> url=0x2b4a5ca1c730, request=0x2b4a5ca1c8d0, old_info=0x2b46b5738320,
> pin_in_cache=0, retry=true,
> allow_multiple=false) at HttpCacheSM.cc:297
> #12 0x005da126 in HttpSM::do_cache_prepare_action
> (this=0x2b4a5ca1c5c0, c_sm=0x2b4a5ca1d7d0, object_read_info=0x2b46b5738320,
> retry=true, allow_multiple=false)
> at HttpSM.cc:4513
> #13 0x005e8850 in HttpSM::do_cache_prepare_write
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4434
> #14 0x005e30ee in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7211
> #15 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #16 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #17 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #18 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #19 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #20 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #21 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #22 0x005d8385 in HttpSM::do_hostdb_lookup (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:3997
> #23 0x005e2ae7 in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:7078
> #24 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #25 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #26 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #27 0x005db6c7 in HttpSM::do_api_callout_internal
> (this=0x2b4a5ca1c5c0) at HttpSM.cc:4875
> #28 0x005e879c in HttpSM::do_api_callout (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:437
> #29 0x005e21de in HttpSM::set_next_state (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:6979
> #30 0x005e2178 in HttpSM::call_transact_and_set_next_state
> (this=0x2b4a5ca1c5c0, f=0) at HttpSM.cc:6945
> #31 0x005cfbc0 in HttpSM::handle_api_return (this=0x2b4a5ca1c5c0) at
> HttpSM.cc:1502
> #32 0x005cfa5c in HttpSM::state_api_callout (this=0x2b4a5ca1c5c0,
> event=0, data=0x0) at HttpSM.cc:1438
> #33 0x005db6c7 in HttpSM::do_api_callout_internal
[jira] [Updated] (TS-3954) Latency with SPDY/HTTP/2 when chunking disabled (not default setting)
[
https://issues.apache.org/jira/browse/TS-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3954:
-
Labels: yahoo (was: )
> Latency with SPDY/HTTP/2 when chunking disabled (not default setting)
> -
>
> Key: TS-3954
> URL: https://issues.apache.org/jira/browse/TS-3954
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2, SPDY
>Reporter: Bryan Call
>Assignee: Bryan Call
> Labels: yahoo
> Fix For: 6.0.1
>
>
> The last frame to tell the client it is the end of the data takes awhile to
> be sent.
> {code}
> [bcall@homer ~]$ nghttp -v -H ':authority: s.yimg.com'
> 'https://l7.ycs.swp.yahoo.com/os/bossnext/0.1.187/js/40.69bc98cf2f62459d4ce9.min.js'
> [ 0.050] Connected
> [ 0.105][NPN] server offers:
> * h2
> * h2-14
> * spdy/3.1
> * spdy/3
> * http/1.1
> * http/1.0
> The negotiated protocol: h2
> [ 0.163] send SETTINGS frame
[jira] [Updated] (TS-3911) New log tag for proxy connection being over SSL, pqssl
[ https://issues.apache.org/jira/browse/TS-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3911: - Assignee: Eric Schwartz > New log tag for proxy connection being over SSL, pqssl > -- > > Key: TS-3911 > URL: https://issues.apache.org/jira/browse/TS-3911 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Eric Schwartz >Assignee: Eric Schwartz > > Want to add a log tag identifying whether the connection between the proxy > and origin is over SSL. We have a similar tag for the client connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3901) Leaking connections from HttpSessionManager
[ https://issues.apache.org/jira/browse/TS-3901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3901: - Labels: yahoo (was: ) > Leaking connections from HttpSessionManager > --- > > Key: TS-3901 > URL: https://issues.apache.org/jira/browse/TS-3901 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Labels: yahoo > > Observed in production. Got the following warnings in diags.log > "Connection leak from http keep-alive system" > Our connections to origin would increase and the number of connections in > CLOSE_WAIT were enormous. > I think the issue was when the origin URL was http with default port. That > URL was remapped to https with default port. The default port stored in > HttpServerSession->server_ip was not updated. > When the connection was closed or timed out of the session pool, it would be > looked up with port 443. But the session was stored via the server_ip value > with port 80 and would never match. > Relatively small change in HTTPHdr::_file_target_cache. > Running the fix in production to verify early results. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3900) Create log tag for server connection reuse
[ https://issues.apache.org/jira/browse/TS-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3900: - Assignee: Eric Schwartz > Create log tag for server connection reuse > -- > > Key: TS-3900 > URL: https://issues.apache.org/jira/browse/TS-3900 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Eric Schwartz >Assignee: Eric Schwartz >Priority: Minor > Labels: yahoo > > There was a log tag % added a while back by [~fpesce] that logged > whether the connection between ATS and the client was reused. There's been > some interest at Yahoo! in a similar tag for whether the connection between > ATS and the origin server was reused. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-315: Assignee: Bryan Call > Add switch to disable config file generation/runtime behavior changing > -- > > Key: TS-315 > URL: https://issues.apache.org/jira/browse/TS-315 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Miles Libbey >Assignee: Bryan Call >Priority: Minor > Labels: A > Fix For: sometime > > > (was yahoo bug 1863676) > Original description > by Michael S. Fischer 2 years ago at 2008-04-09 09:52 > In production, in order to improve site stability, it is imperative that TS > never accidentally overwrite its own > configuration files. > For this reason, we'd like to request a switch be added to TS, preferably via > the command line, that disables all > automatic configuration file generation or other runtime behavioral changes > initiated by any form of IPC other than > 'traffic_line -x' (including the web interface, etc.) > > > Comment 1 > by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 > A very crucial request, in my opinion. If TS needs to be able to read > command-line config changes on the fly, these > changes should be stored in another config file (for example > remap.config.local instead of remap.config). We have a > patch config package that overwrites 4 of the config files under > /home/conf/ts/, and with all packages > we'd like to think that the content of these files can't change outside our > control. > > Comment 2 > by Bryan Call 2 years ago at 2008-04-09 11:02:46 > traffic_line -x doesn't modify the configuration, it reloads the > configuration files. If we want to have an option for > this it would be good to have it as an option configuration file (CONFIG > proxy.config.write_protect INT 1). > It would be an equivalent of write protecting floppies (ahh the memories)... > > > Comment 3 > by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 > I don't think it would be a good idea to have this in the configuration file, > as it would introduce a chicken/egg > problem. > > > Comment 4 > by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 > So I'm not 100% positive that this isn't just a bad interaction. Now, it's > only > triggered when trafficserver is running, but usually what ends up happening > is that we get a records.config which > looks like it's the default config that comes with the trafficserver package. > It's possible it's all one and the same issue, or we might have two issues. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3884) Trafficserver modifies its config files, doesn't interact well with puppet/chef/etc
[ https://issues.apache.org/jira/browse/TS-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3884: - Assignee: Bryan Call > Trafficserver modifies its config files, doesn't interact well with > puppet/chef/etc > --- > > Key: TS-3884 > URL: https://issues.apache.org/jira/browse/TS-3884 > Project: Traffic Server > Issue Type: Bug >Reporter: zxcvbn4038 >Assignee: Bryan Call > Labels: Yahoo > > Tumblr uses puppet for configuration management, I believe Y! will soon use > Chef. > Issue is that when Traffic Server reads its configuration files it changes > white space and adds additional entries. The next time puppet runs it sees > the files have changed, restores the copies from the repository, and sends a > reload signal. Trafficserver then modifies the files again and the cycle > repeats. > To break the cycle I am requesting: > 1) That Traffic Server does not modify its configuration files unless > explicitly told to via the traffic_line command. > 2) That it only updates the entry it was instructed to change > 3) That it does not modify the white space of any other entry > 4) That it does not add or remove any additional entries to/from the file > Not required, but more of a nic-pick: > 5) If traffic server has preferred whitespace then default configuration > files that ship with the product should conform (i.e. first invocation > shouldn't cause the files to change), its odd that we ship files that don't > conform to our own preferences/standards. > 6) If we intend to exhaustively listing every traffic server option and its > default value in the default records.conf that ships with traffic server, we > should audit pre-release and make sure that is up to date and grouped > logically instead of trying to append entries on first invocation. If we > don't want to do that work then maybe ship a minimal records.conf with a few > example entires and a link to the documentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3895) Mutex leak for TLS connections going to the origin
[ https://issues.apache.org/jira/browse/TS-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3895: - Labels: yahoo (was: ) > Mutex leak for TLS connections going to the origin > -- > > Key: TS-3895 > URL: https://issues.apache.org/jira/browse/TS-3895 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Affects Versions: 5.3.0 >Reporter: Bryan Call >Assignee: Bryan Call > Labels: yahoo > Fix For: 6.0.0 > > > The action mutex clear was removed in some "clean up" work in > SSLNetVConnection::free() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better
[ https://issues.apache.org/jira/browse/TS-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3875: - Labels: yahoo (was: ) > Have SPDY allocate the MIOBuffers directly so we can track memory usage better > -- > > Key: TS-3875 > URL: https://issues.apache.org/jira/browse/TS-3875 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Affects Versions: 5.3.0 >Reporter: Bryan Call >Assignee: Bryan Call > Labels: yahoo > Fix For: 6.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3869) HTTP/2 Stream uses the clients window size for the servers setting
[ https://issues.apache.org/jira/browse/TS-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3869: - Labels: yahoo (was: ) HTTP/2 Stream uses the clients window size for the servers setting -- Key: TS-3869 URL: https://issues.apache.org/jira/browse/TS-3869 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Assignee: Bryan Call Labels: yahoo Fix For: 6.0.0 The Http2Stream class incorrectly uses the clients window size for initializing the servers window size. In Chrome this defaults to 10MB. Since the client client thinks it the window size is 1MB, the amount the server said it was, and the server thinks it is 10MB the client will only be able to send 1MB of data and then wait until it gets more credit. More credit isn't given until there is 16KB left on the stream and it will never get there since 10MB - 1MB = 9MB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3850) Add accept and no activity timeouts for HTTP/2
[ https://issues.apache.org/jira/browse/TS-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3850: - Labels: yahoo (was: ) Add accept and no activity timeouts for HTTP/2 -- Key: TS-3850 URL: https://issues.apache.org/jira/browse/TS-3850 Project: Traffic Server Issue Type: Improvement Components: HTTP/2 Reporter: Bryan Call Assignee: Bryan Call Labels: yahoo Fix For: 6.0.0 Currently there are no timeouts set on the HTTP/2 connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2940) the Fatal() macro always crashes
[
https://issues.apache.org/jira/browse/TS-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2940:
-
Labels: yahoo (was: )
the Fatal() macro always crashes
Key: TS-2940
URL: https://issues.apache.org/jira/browse/TS-2940
Project: Traffic Server
Issue Type: Bug
Components: Core, Logging
Reporter: James Peach
Assignee: James Peach
Labels: yahoo
Fix For: 5.1.0
{{Diags::error_va}} uses the argument list twice, causing a crash in printf,
father than logging a fatal error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2375) Error when using ascii logging format: There are more field markers than fields
[
https://issues.apache.org/jira/browse/TS-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2375:
-
Labels: yahoo (was: )
Error when using ascii logging format: There are more field markers than
fields
---
Key: TS-2375
URL: https://issues.apache.org/jira/browse/TS-2375
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 4.0.2, 4.1.2
Reporter: David Carlin
Assignee: Bryan Call
Labels: yahoo
Fix For: 6.1.0
I noticed the following on an ats 4.0.2 host in diags.log:
{noformat}[Nov 20 15:08:29.627] Server {0x2b732fe9c700} NOTE: There are more
field markers than fields; cannot process log entry{noformat}
It only happens about every fifth time you start ATS. That message will fill
diags.log and nothing is written to squid.log
I then upgraded to 4.1.1 as a test, and the same thing happened except there
was additional error information:
{noformat}[Nov 20 15:40:53.656] Server {0x2b568aac8700} NOTE: There are more
field markers than fields; cannot process log entry
[Nov 20 15:40:53.656] Server {0x2b568aac8700} ERROR: Failed to convert
LogBuffer to ascii, have dropped (232) bytes.{noformat}
The convert to ascii message tipped me off that this could be the source of
the problem. Up until now we've been using the binary log format, so perhaps
this is why I didn't run into this in the past. I then changed the log
format back to binary, and I was unable to reproduce the issue - so it seems
related to ascii logging.
Here is our logs_xml.config:
{noformat}
LogFormat
Name = ats_generic_config/
Format = %cqtq %ttms %chi %crc %pssc %psql %cqhm %cquc
%caun %phr/%pqsn %psct %cquuc f1 f2 f3 f4/
/LogFormat
LogObject
Format = ats_generic_config/
Filename = squid/
Mode = ascii/
/LogObject
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3809) Corrupt debug log messages LogFormat::parse_format_string
[
https://issues.apache.org/jira/browse/TS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3809:
-
Labels: yahoo (was: )
Corrupt debug log messages LogFormat::parse_format_string
-
Key: TS-3809
URL: https://issues.apache.org/jira/browse/TS-3809
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 5.3.0
Reporter: David Carlin
Labels: yahoo
Reporting this in case its indicative of a problem. When I start ATS 5.3.0 I
see these debug messages with unprintable characters:
Maybe related to TS-2375 ?
{code}
Jul 31 19:46:18.982] Server {0x2ad2e4364be0} DEBUG: (log-format)
LogFormat::parse_format_string: field_count=12,
cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct, � � � �/� � � �
� �/� �
[Jul 31 19:46:18.982] Server {0x2ad2e4364be0} DEBUG: (log-format)
LogFormat::parse_format_string: field_count=6,
chi,caun,cqtn,cqtx,pssc,pscl, � - � [�] � � �
[Jul 31 19:46:18.982] Server {0x2ad2e4364be0} DEBUG: (log-format)
LogFormat::parse_format_string: field_count=15,
chi,caun,cqtn,cqtx,pssc,pscl,sssc,sscl,cqbl,pqbl,cqhl,pshl,pqhl,sshl,tts,
� - � [�] � � � � � � � � � � � �
[Jul 31 19:46:18.983] Server {0x2ad2e4364be0} DEBUG: (log-format)
LogFormat::parse_format_string: field_count=19,
chi,caun,cqtn,cqtx,pssc,pscl,sssc,sscl,cqbl,pqbl,cqhl,pshl,pqhl,sshl,tts,phr,cfsc,pfsc,crc,
� - � [�] � � � � � � � � � � � � � � � �
[Jul 31 19:46:18.983] Server {0x2ad2e4364be0} DEBUG: (log-format)
LogFormat::parse_format_string: field_count=13,
cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct,cquuc, � � � � �
� � � � �/� � � f1 f2 f3 f4
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
[
https://issues.apache.org/jira/browse/TS-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2447:
-
Labels: yahoo (was: )
Cache fails to load / initialize, seems stuck on directory entry cleanup
Key: TS-2447
URL: https://issues.apache.org/jira/browse/TS-2447
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Labels: yahoo
Fix For: sometime
We had an issue where a number of machines would not startup properly. They
get stuck on reading / initializing the cache. It initializes the caches with
{code}
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 65536
[Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
{code}
After this, it enters a stage where it’s doing a *lot* of dir_clean events:
{code}
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0a0 tag 0 boffset 0 b 0x7f3edcd6f0a0 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0c8 tag 0 boffset 0 b
[jira] [Commented] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
[
https://issues.apache.org/jira/browse/TS-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647659#comment-14647659
]
David Carlin commented on TS-2447:
--
I am seeing this on almost every box I enable debugging. Possibly related to
5.0.1 - 5.3.0 migration.
traffic_server -Cclear fixes the issue.
Cache fails to load / initialize, seems stuck on directory entry cleanup
Key: TS-2447
URL: https://issues.apache.org/jira/browse/TS-2447
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Labels: yahoo
Fix For: sometime
We had an issue where a number of machines would not startup properly. They
get stuck on reading / initializing the cache. It initializes the caches with
{code}
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 65536
[Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
{code}
After this, it enters a stage where it’s doing a *lot* of dir_clean events:
{code}
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
[jira] [Updated] (TS-3797) Crashes due to cross-thread race conditions
[
https://issues.apache.org/jira/browse/TS-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3797:
-
Labels: yahoo (was: )
Crashes due to cross-thread race conditions
---
Key: TS-3797
URL: https://issues.apache.org/jira/browse/TS-3797
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.3.0
Reporter: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
We had seen crashes with the following stack trace occasionally, but
recently we have found an environment where these crashes happen so
frequently that running ATS with global session pools is not feasible.
{code}
#0 0x004fac6e in PtrIOBufferBlock::operator IOBufferBlock* (
this=0x10) at ../lib/ts/Ptr.h:300
#1 0x005109a2 in IOBufferReader::read_avail (this=0x0)
at ../iocore/eventsystem/P_IOBuffer.h:606
#2 0x00777b54 in write_to_net_io (nh=0x2acc365358a0,
vc=0x2acd38024960, thread=0x2acc36532010) at UnixNetVConnection.cc:540
#3 0x0077747a in write_to_net (nh=0x2acc365358a0, vc=0x2acd38024960,
thread=0x2acc36532010) at UnixNetVConnection.cc:407
#4 0x00770378 in NetHandler::mainNetEvent (this=0x2acc365358a0,
event=5, e=0x2244730) at UnixNet.cc:562
#5 0x00510560 in Continuation::handleEvent (this=0x2acc365358a0,
event=5, data=0x2244730) at ../iocore/eventsystem/I_Continuation.h:145
#6 0x00796ffe in EThread::process_event (this=0x2acc36532010,
e=0x2244730, calling_code=5) at UnixEThread.cc:128
#7 0x00797508 in EThread::execute (this=0x2acc36532010)
at UnixEThread.cc:252
#8 0x007965a9 in spawn_thread_internal (a=0x2115540) at Thread.cc:85
#9 0x2acc2edd49d1 in start_thread () from /lib64/libpthread.so.0
#10 0x0032750e88fd in clone () from /lib64/libc.so.6
{code}
See
https://cwiki.apache.org/confluence/display/TS/Threading+Issues+And+NetVC+Migration
for analysis of the crash and a suggested solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3797) Crashes due to cross-thread race conditions
[
https://issues.apache.org/jira/browse/TS-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3797:
-
Affects Version/s: 5.3.0
Crashes due to cross-thread race conditions
---
Key: TS-3797
URL: https://issues.apache.org/jira/browse/TS-3797
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.3.0
Reporter: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
We had seen crashes with the following stack trace occasionally, but
recently we have found an environment where these crashes happen so
frequently that running ATS with global session pools is not feasible.
{code}
#0 0x004fac6e in PtrIOBufferBlock::operator IOBufferBlock* (
this=0x10) at ../lib/ts/Ptr.h:300
#1 0x005109a2 in IOBufferReader::read_avail (this=0x0)
at ../iocore/eventsystem/P_IOBuffer.h:606
#2 0x00777b54 in write_to_net_io (nh=0x2acc365358a0,
vc=0x2acd38024960, thread=0x2acc36532010) at UnixNetVConnection.cc:540
#3 0x0077747a in write_to_net (nh=0x2acc365358a0, vc=0x2acd38024960,
thread=0x2acc36532010) at UnixNetVConnection.cc:407
#4 0x00770378 in NetHandler::mainNetEvent (this=0x2acc365358a0,
event=5, e=0x2244730) at UnixNet.cc:562
#5 0x00510560 in Continuation::handleEvent (this=0x2acc365358a0,
event=5, data=0x2244730) at ../iocore/eventsystem/I_Continuation.h:145
#6 0x00796ffe in EThread::process_event (this=0x2acc36532010,
e=0x2244730, calling_code=5) at UnixEThread.cc:128
#7 0x00797508 in EThread::execute (this=0x2acc36532010)
at UnixEThread.cc:252
#8 0x007965a9 in spawn_thread_internal (a=0x2115540) at Thread.cc:85
#9 0x2acc2edd49d1 in start_thread () from /lib64/libpthread.so.0
#10 0x0032750e88fd in clone () from /lib64/libc.so.6
{code}
See
https://cwiki.apache.org/confluence/display/TS/Threading+Issues+And+NetVC+Migration
for analysis of the crash and a suggested solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3785) List --command options in traffic_server usage information
[ https://issues.apache.org/jira/browse/TS-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3785: - Priority: Minor (was: Major) List --command options in traffic_server usage information -- Key: TS-3785 URL: https://issues.apache.org/jira/browse/TS-3785 Project: Traffic Server Issue Type: Improvement Components: Docs, Documentation Affects Versions: 5.3.0 Reporter: David Carlin Priority: Minor Labels: yahoo Please update traffic_server --help (-h) output to show all the possible options for the --command (-C) option. For example, there is currently no way to know -Cverify_config exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3785) List --command options in traffic_server usage information
[ https://issues.apache.org/jira/browse/TS-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3785: - Affects Version/s: 5.3.0 List --command options in traffic_server usage information -- Key: TS-3785 URL: https://issues.apache.org/jira/browse/TS-3785 Project: Traffic Server Issue Type: Improvement Components: Docs, Documentation Affects Versions: 5.3.0 Reporter: David Carlin Labels: yahoo Please update traffic_server --help (-h) output to show all the possible options for the --command (-C) option. For example, there is currently no way to know -Cverify_config exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3785) List --command options in traffic_server usage information
[ https://issues.apache.org/jira/browse/TS-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3785: - Labels: yahoo (was: ) List --command options in traffic_server usage information -- Key: TS-3785 URL: https://issues.apache.org/jira/browse/TS-3785 Project: Traffic Server Issue Type: Improvement Components: Docs, Documentation Affects Versions: 5.3.0 Reporter: David Carlin Labels: yahoo Please update traffic_server --help (-h) output to show all the possible options for the --command (-C) option. For example, there is currently no way to know -Cverify_config exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3785) List --command options in traffic_server usage information
David Carlin created TS-3785: Summary: List --command options in traffic_server usage information Key: TS-3785 URL: https://issues.apache.org/jira/browse/TS-3785 Project: Traffic Server Issue Type: Improvement Components: Docs, Documentation Reporter: David Carlin Please update traffic_server --help (-h) output to show all the possible options for the --command (-C) option. For example, there is currently no way to know -Cverify_config exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3608) SSL client code does not validate upstream hostname
[ https://issues.apache.org/jira/browse/TS-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3608: - Labels: yahoo (was: ) SSL client code does not validate upstream hostname --- Key: TS-3608 URL: https://issues.apache.org/jira/browse/TS-3608 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Uri Shachar Assignee: Uri Shachar Labels: yahoo Fix For: 6.0.0 Our SSL client side certificate validation does not validate that the upstream certificate actually matches the request hostname/IP. Openssl added a check for this (X509_check_host) in 1.0.2 -- but that version is still far from becoming mainstream (and the implementation there is somewhat overcomplicated for our needs). Fix is to validate (when client side validation is turned on) according to RFC6125 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3710) Crash in TLS with 6.0.0, related to the session cleanup additions
[
https://issues.apache.org/jira/browse/TS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3710:
-
Labels: yahoo (was: )
Crash in TLS with 6.0.0, related to the session cleanup additions
-
Key: TS-3710
URL: https://issues.apache.org/jira/browse/TS-3710
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Priority: Critical
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3710-2.diff, ts-3710-final-2.diff, ts-3710.diff
{code}
==9570==ERROR: AddressSanitizer: heap-use-after-free on address
0x60649f48 at pc 0xb9f969 bp 0x2b8dbc348920 sp 0x2b8dbc348918
READ of size 8 at 0x60649f48 thread T8 ([ET_NET 7])
#0 0xb9f968 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#1 0xb9f968 in read_signal_and_update
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:142
#2 0xb9f968 in UnixNetVConnection::mainEvent(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:1115
#3 0xb7daf7 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#4 0xb7daf7 in InactivityCop::check_inactivity(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNet.cc:102
#5 0xc21ffe in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#6 0xc21ffe in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#7 0xc241f7 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:207
#8 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#9 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
#10 0x2b8db585f1ac in __clone (/lib64/libc.so.6+0xf61ac)
0x60649f48 is located 8 bytes inside of 56-byte region
[0x60649f40,0x60649f78)
freed by thread T8 ([ET_NET 7]) here:
#0 0x2b8db1bf3117 in operator delete(void*)
../../.././libsanitizer/asan/asan_new_delete.cc:81
#1 0xb5b20e in SSLNextProtocolTrampoline::ioCompletionEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/SSLNextProtocolAccept.cc:89
#2 0xbb2eef in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#3 0xbb2eef in read_signal_and_update
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:142
#4 0xbb2eef in read_signal_done
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:203
#5 0xbb2eef in UnixNetVConnection::readSignalDone(int, NetHandler*)
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:957
#6 0xb55d6d in SSLNetVConnection::net_read_io(NetHandler*, EThread*)
/usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:480
#7 0xb748fc in NetHandler::mainNetEvent(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNet.cc:516
#8 0xc24e89 in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#9 0xc24e89 in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#10 0xc24e89 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:252
#11 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#12 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
previously allocated by thread T8 ([ET_NET 7]) here:
#0 0x2b8db1bf2c9f in operator new(unsigned long)
../../.././libsanitizer/asan/asan_new_delete.cc:50
#1 0xb59f8b in SSLNextProtocolAccept::mainEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/SSLNextProtocolAccept.cc:134
#2 0xb888e9 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#3 0xb888e9 in NetAccept::acceptFastEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/UnixNetAccept.cc:466
#4 0xc24e89 in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#5 0xc24e89 in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#6 0xc24e89 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:252
#7 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#8 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
Thread T8 ([ET_NET 7]) created by T0 ([ET_NET 0]) here:
#0 0x2b8db1bc186a in __interceptor_pthread_create
[jira] [Updated] (TS-3752) Problem with larger headers and HTTP/2
[ https://issues.apache.org/jira/browse/TS-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3752: - Labels: yahoo (was: ) Problem with larger headers and HTTP/2 -- Key: TS-3752 URL: https://issues.apache.org/jira/browse/TS-3752 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Bryan Call Labels: yahoo There is a problem when ATS receives a HEADERS or CONTINUATION frame on the HEADERS frame and there is no end of header to be decoded. If there is 1 small header at the beginning of the frame it will work, but if a large header either starts at the beginning of the frame or started on the previous frame and don't end until the next frame then the decoded_bytes will be 0. This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3591) TSHttpIsInternalRequest always returns TS_SUCCESS over http2
[ https://issues.apache.org/jira/browse/TS-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3591: - Labels: yahoo (was: ) TSHttpIsInternalRequest always returns TS_SUCCESS over http2 Key: TS-3591 URL: https://issues.apache.org/jira/browse/TS-3591 Project: Traffic Server Issue Type: Bug Reporter: Scott Beardsley Labels: yahoo I am playing with 5.3.0 and I notice that TSHttpIsInternalRequest() is always returning TS_SUCCESS when using HTTP 2 (it works fine with SPDY). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3596) TSHttpTxnPluginTagGet() returns fetchSM over H2
[ https://issues.apache.org/jira/browse/TS-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3596: - Labels: yahoo (was: ) TSHttpTxnPluginTagGet() returns fetchSM over H2 - Key: TS-3596 URL: https://issues.apache.org/jira/browse/TS-3596 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Scott Beardsley Labels: yahoo Fix For: 6.1.0 This should probably return something else, right? Maybe HTTP2 instead? We would like a way to identify H2 requests from SPDY and/or H1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3590) H2 fetch streams marked as internal requests incorrectly
[ https://issues.apache.org/jira/browse/TS-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3590: - Labels: yahoo (was: ) H2 fetch streams marked as internal requests incorrectly Key: TS-3590 URL: https://issues.apache.org/jira/browse/TS-3590 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Sudheer Vinukonda Labels: yahoo Fix For: 5.3.1, 6.0.0 A bug similar to TS-2906 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3595) Cookie header split into multiple lines with H2
[
https://issues.apache.org/jira/browse/TS-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3595:
-
Labels: yahoo (was: )
Cookie header split into multiple lines with H2
---
Key: TS-3595
URL: https://issues.apache.org/jira/browse/TS-3595
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Scott Beardsley
Priority: Critical
Labels: yahoo
Fix For: 6.1.0
I've noticed that the Cookie header is now split into multiple lines. I can't
tell if this is a part of the HPACK spec but it is definitely different from
the SPDY 3.1 TS implementation.
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :authority: search.yahoo.com
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :method: GET
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :path: /
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: :scheme: https
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Accept: */*
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Accept-Encoding: gzip, deflate, sdch
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Accept-Language: en-US,en;q=0.8,it-IT;q=0.6,it;q=0.4,ja;q=0.2
[May 12 06:08:10.630] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Cookie: AO=u=1o=1
[May 12 06:08:10.631] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Cookie: B=abc123
[May 12 06:08:10.631] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: Cookie: DSS=321321
[May 12 06:08:10.631] Server {0x2b387f285700} DEBUG: (http2_hpack_decode)
Decoded field: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3577) ATS with --enable-static-proxy does not compile
[
https://issues.apache.org/jira/browse/TS-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3577:
-
Labels: yahoo (was: )
ATS with --enable-static-proxy does not compile
---
Key: TS-3577
URL: https://issues.apache.org/jira/browse/TS-3577
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Thomas Jackson
Labels: yahoo
Fix For: 6.1.0
Lots of errors in the build:
{code}
libtool: link: warning: complete static linking is impossible in this
configuration
../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT,
char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function
`RecReadConfigFile(bool)':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633:
undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
../lib/records/librecords_p.a(P_RecCore.o): In function
`RecSyncConfigToTB(textBuffer*, bool*)':
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702:
undefined reference to `textBuffer::reUse()'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704:
undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774:
undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:760:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:762:
undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
../lib/records/librecords_p.a(P_RecCore.o):/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:752:
more undefined references to `textBuffer::copyFrom(void const*, unsigned
int)' follow
../lib/records/librecords_p.a(P_RecCore.o): In function
`RecSetSyncRequired(char*, bool)':
[jira] [Updated] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3642: - Description: Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) was: Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior. proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3642: - Affects Version/s: 5.3.0 proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3642) proxy.config.http.share_server_sessions not working
David Carlin created TS-3642: Summary: proxy.config.http.share_server_sessions not working Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: David Carlin Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT
[ https://issues.apache.org/jira/browse/TS-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14561404#comment-14561404 ] David Carlin commented on TS-3036: -- TS-2944 accomplishes something very similar, but TS-3036 seems more complete. TS-2944 only implements TCP_MEM_HIT cache result code; where as TS-3036 shows HIT RAM for a variety of cache result codes. Examples: HIT_RAM ERR_CLIENT_ABORT/200 HIT_RAM TCP_IMS_HIT/304 You wouldn't have this additional information with TS-2944. Add logging field to define the cache medium used to serve a HIT Key: TS-3036 URL: https://issues.apache.org/jira/browse/TS-3036 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Ryan Frantz Assignee: Leif Hedstrom Labels: review Fix For: 5.3.0 I want to be able to differentiate between RAM cache HITs and disk cache HITs. Add a logging field to inform the administrator if the HIT came from RAM, at least. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3643) TS-2944 changes logging format / breaks compatibility
[ https://issues.apache.org/jira/browse/TS-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3643: - Affects Version/s: 5.3.0 TS-2944 changes logging format / breaks compatibility - Key: TS-3643 URL: https://issues.apache.org/jira/browse/TS-3643 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Affects Versions: 5.3.0 Reporter: David Carlin TS-2944 broke out log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3643) TS-2944 changes logging format / breaks compatibility
[ https://issues.apache.org/jira/browse/TS-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3643: - Description: TS-2944 broke our log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? was: TS-2944 broke out log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? TS-2944 changes logging format / breaks compatibility - Key: TS-3643 URL: https://issues.apache.org/jira/browse/TS-3643 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Affects Versions: 5.3.0 Reporter: David Carlin TS-2944 broke our log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3534) Wiretracing for SSL connections
[ https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559290#comment-14559290 ] David Carlin commented on TS-3534: -- I've found it very valuable. In order to trace SSL in wireshark I need to: 1) Disable PFS, remove DHE ciphers 2) Disable SSL Session ID Cache and Tickets so I can capture the full handshake. 3) Copy private key off server to use with Wireshark, or use tshark on the remote host 4) Restart ATS With Eric's patch i can enable/disable SSL wire tracing it whenever I want. I like that I don't have to restart ATS - doing so may clear the condition I'm trying to capture. Wiretracing for SSL connections --- Key: TS-3534 URL: https://issues.apache.org/jira/browse/TS-3534 Project: Traffic Server Issue Type: New Feature Components: Logging, Tools Reporter: Eric Schwartz Assignee: Eric Schwartz Fix For: sometime Opening a ticket for discussion of the wiretracing change I made on our internal version of ATS. The change allows for tracing requests through ATS for: a small percentage of traffic, traffic from a certain IP and/or traffic to a specific origin. These settings can be combined. The main updates are to SSLNetVConnection and UnixNetVConnection (adding the trace logic) and to the Logging APIs (to add the special trace logs). One change is made to HttpSM to allow client and server traces to be associated with one another. [~dcarlin] has some notes from the summit on the initial discussion. I'll add a pull request with actual code for people to look at shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3560) Please enable proxy.config.http.slow.log.threshold configuration via conf_remap plugin
[ https://issues.apache.org/jira/browse/TS-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3560: - Assignee: Alan M. Carroll Please enable proxy.config.http.slow.log.threshold configuration via conf_remap plugin -- Key: TS-3560 URL: https://issues.apache.org/jira/browse/TS-3560 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: David Carlin Assignee: Alan M. Carroll Please make proxy.config.http.slow.log.threshold configurable via conf_remap - we want to be able to enable it on a per-remap basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3560) Please enable proxy.config.http.slow.log.threshold configuration via conf_remap plugin
David Carlin created TS-3560: Summary: Please enable proxy.config.http.slow.log.threshold configuration via conf_remap plugin Key: TS-3560 URL: https://issues.apache.org/jira/browse/TS-3560 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: David Carlin Please make proxy.config.http.slow.log.threshold configurable via conf_remap - we want to be able to enable it on a per-remap basis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3545) Make traffic_line and traffic_ctl more verbose
David Carlin created TS-3545: Summary: Make traffic_line and traffic_ctl more verbose Key: TS-3545 URL: https://issues.apache.org/jira/browse/TS-3545 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: David Carlin Couple suggestions: Can 'traffic_line -s' and 'traffic_ctl config set' send a warning after making a setting change that it will take 5-10 seconds to take effect? Currently the command will warn you when a reboot is needed, but it would be handy if it by default reported when a reboot is unnecessary as well. Neither tool outputs anything usually when making a setting change, leaving the user to wonder if it worked or not.. I only recently found out there was a delay in making a change and having it take effect; I frequently just thought traffic_line -s didn't work for a particular setting, but I may not have been waiting long enough. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3534) Wiretracing for SSL connections
[ https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503276#comment-14503276 ] David Carlin commented on TS-3534: -- Notes I took during my presentation: * spdy headers compressed * [~zwoop] interested in non-tls traffic * [~briang] had ideas relating to correlating client/origin connections - i.e., only print origin traffic related to client connection we are interested in. * [~mlibbey] is interested in per remap enabling * Plugin vs. Core - plugin would require restart; Apple/Comcast can’t restart ATS easily. [~sudheerv] pointed out that a restart might clear condition trying to catch. * Several people were interested in suggested output to pcap file - then you could use Wireshark's facilities to follow the connection traffic. ** [~briang] suggested to synthesize sequence numbers to facilitate this. * Integrate [~sudheerv]'s per-ip debug feature? Or is this unrelated? Susan's notes: General agreement that this is a good feature. 1. API to enable trace on a VC 2. API to process raw packet. Agreement that should be generalized to TCP beyond. Currently all in core. Idea to dump to a pcap file. Wiretracing for SSL connections --- Key: TS-3534 URL: https://issues.apache.org/jira/browse/TS-3534 Project: Traffic Server Issue Type: New Feature Components: Logging, Tools Reporter: Eric Schwartz Opening a ticket for discussion of the wiretracing change I made on our internal version of ATS. The change allows for tracing requests through ATS for: a small percentage of traffic, traffic from a certain IP and/or traffic to a specific origin. These settings can be combined. The main updates are to SSLNetVConnection and UnixNetVConnection (adding the trace logic) and to the Logging APIs (to add the special trace logs). One change is made to HttpSM to allow client and server traces to be associated with one another. [~dcarlin] has some notes from the summit on the initial discussion. I'll add a pull request with actual code for people to look at shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3534) Wiretracing for SSL connections
[ https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503276#comment-14503276 ] David Carlin edited comment on TS-3534 at 4/20/15 5:41 PM: --- Notes I took during my presentation: * spdy headers compressed * [~zwoop] interested in non-tls traffic * [~briang] had ideas on correlating client/origin connections - i.e., only print origin traffic related to client connection we are interested in. * [~mlibbey] is interested in per-remap enabling * Plugin vs. Core - plugin would require restart; Apple/Comcast can’t restart ATS easily. [~sudheerv] pointed out that a restart might clear condition trying to catch. * Several people were interested in suggested output to pcap file - then you could use Wireshark's facilities to follow the connection traffic. ** [~briang] suggested to synthesize sequence numbers to facilitate this. * Integrate [~sudheerv]'s per-ip debug feature? Or is this unrelated? Susan's notes: General agreement that this is a good feature. 1. API to enable trace on a VC 2. API to process raw packet. Agreement that should be generalized to TCP beyond. Currently all in core. Idea to dump to a pcap file. was (Author: dcarlin): Notes I took during my presentation: * spdy headers compressed * [~zwoop] interested in non-tls traffic * [~briang] had ideas relating to correlating client/origin connections - i.e., only print origin traffic related to client connection we are interested in. * [~mlibbey] is interested in per remap enabling * Plugin vs. Core - plugin would require restart; Apple/Comcast can’t restart ATS easily. [~sudheerv] pointed out that a restart might clear condition trying to catch. * Several people were interested in suggested output to pcap file - then you could use Wireshark's facilities to follow the connection traffic. ** [~briang] suggested to synthesize sequence numbers to facilitate this. * Integrate [~sudheerv]'s per-ip debug feature? Or is this unrelated? Susan's notes: General agreement that this is a good feature. 1. API to enable trace on a VC 2. API to process raw packet. Agreement that should be generalized to TCP beyond. Currently all in core. Idea to dump to a pcap file. Wiretracing for SSL connections --- Key: TS-3534 URL: https://issues.apache.org/jira/browse/TS-3534 Project: Traffic Server Issue Type: New Feature Components: Logging, Tools Reporter: Eric Schwartz Opening a ticket for discussion of the wiretracing change I made on our internal version of ATS. The change allows for tracing requests through ATS for: a small percentage of traffic, traffic from a certain IP and/or traffic to a specific origin. These settings can be combined. The main updates are to SSLNetVConnection and UnixNetVConnection (adding the trace logic) and to the Logging APIs (to add the special trace logs). One change is made to HttpSM to allow client and server traces to be associated with one another. [~dcarlin] has some notes from the summit on the initial discussion. I'll add a pull request with actual code for people to look at shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3509) Access permissions for storage entries in cache.config changed
[
https://issues.apache.org/jira/browse/TS-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499224#comment-14499224
]
David Carlin commented on TS-3509:
--
Please close as invalid. Appears to be an intermittent issue with device
permissions - 5.0.1 isn't affected, but the problem in 5.3.0 doesn't appear to
be ATS.
Access permissions for storage entries in cache.config changed
--
Key: TS-3509
URL: https://issues.apache.org/jira/browse/TS-3509
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 5.3.0
Reporter: Bryan Call
Priority: Blocker
Fix For: 6.0.0
It looks like 5.3.0 drops from root before opening up the disk storage now:
{code}
[Apr 8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init)
Store::read_config: /dev/dm-4
[Apr 8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init)
Store::read_config - ns = new Span; ns-init(/dev/dm-4,-1), forced volume=-1
[Apr 8 23:52:33.227] Server {0x7ff106a86800} DEBUG: (cache_init)
Store::read_config - could not initialize storage /dev/dm-4 [unable to
access file]
[bcall@l1 ~]$ ll /dev/dm-4
brw-rw 1 root disk 253, 4 Apr 8 23:52 /dev/dm-4
[bcall@l1 ~]$ chmod 666 /dev/dm-4
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280710#comment-14280710 ] David Carlin commented on TS-153: - amc/sudheerv came up with proxy.config.connections.threshold_shed_idle - I like that, its succinct and is very descriptive about whats accomplished with this setting Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280769#comment-14280769 ] David Carlin commented on TS-153: - proxy.config.net.threshold_shed_idle_in is good Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Priority: Minor Labels: A Fix For: 5.3.0 Attachments: ts153.diff (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3243) Warnings from loading legitimate TLS certificates
[
https://issues.apache.org/jira/browse/TS-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253590#comment-14253590
]
David Carlin commented on TS-3243:
--
Also seeing this when testing 5.2.0 hosts:
WARNING: previously indexed wildcard certificate for '*.yimg.com' as
'com.yimg.', cannot index it with SSL_CTX #2 now
Warnings from loading legitimate TLS certificates
-
Key: TS-3243
URL: https://issues.apache.org/jira/browse/TS-3243
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Fix For: 5.3.0
When loading a legitimate certificate (from Go Daddy), which has a domain
name of trafficserver.apache.org as well as some SNs which includes
trafficserver.apache.org as well, we get these warnings:
{code}
[Dec 17 16:01:19.540] Server {0x2b58fdcadf40} NOTE: loading SSL certificate
configuration from /usr/local/etc/trafficserver/ssl_multicert.config
[Dec 17 16:01:19.545] Server {0x2b58fdcadf40} WARNING: previously indexed
'trafficserver.apache.org' with SSL_CTX 0x1, cannot index it with SSL_CTX #2
now
{code}
I've looked at a couple certs from GD, and this practice seems normal. I
don't think we should warn on this case, if the domain name for the cert is
duplicated in the SN, just ignore the latter right ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2399) Disk cache raw device permissions being bypassed
[
https://issues.apache.org/jira/browse/TS-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin closed TS-2399.
Resolution: Invalid
This isn't an issue.
I didn't realize the rc script was being run as root, thats why it can open the
raw device regardless of permissions but invoking 'traffic_server' alone
doesn't work.
Disk cache raw device permissions being bypassed
Key: TS-2399
URL: https://issues.apache.org/jira/browse/TS-2399
Project: Traffic Server
Issue Type: Bug
Components: Cache, Core
Reporter: David Carlin
Assignee: Alan M. Carroll
Fix For: 5.3.0
Disk cache raw device permissions:
{noformat}brw-rw 1 root disk 253, 4 Nov 26 16:03 /dev/dm-4
{noformat}
If I run 'traffic_server' by itself, I can't use the cache - I get permission
errors opening it up:
{noformat}
[Nov 26 16:56:42.976] Server {0x2b4e29878540} WARNING: unable to open
'/dev/dm-4': -13, Permission denied
[Nov 26 16:56:42.976] Server {0x2b4e29878540} WARNING: could not initialize
storage /dev/dm-4 [unable to open]
[Nov 26 16:56:42.976] Server {0x2b4e29878540} NOTE: cache clustering disabled
{noformat}
However, I can I start ATS fine and use the raw device disk cache via the
trafficserver startup script.
These docs indicate that I should be setting the owner to the user that ATS
runs as, but I don't need to as long as I start via the script:
https://cwiki.apache.org/confluence/display/TS/FAQ#FAQ-rawdisk
Once I change ownership of /dev/dm-4 to user ATS is run as, then I can launch
traffic_server by itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3133) Logging NOTE filling up diags.log
[
https://issues.apache.org/jira/browse/TS-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14171170#comment-14171170
]
David Carlin commented on TS-3133:
--
I like this idea, as currently these 'exceeds the maximum payload' mask other
useful messages in diags.log. Ultimately it would be nice if TS-306 was
addressed as well.
Logging NOTE filling up diags.log
-
Key: TS-3133
URL: https://issues.apache.org/jira/browse/TS-3133
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Affects Versions: 5.0.1
Reporter: Sudheer Vinukonda
Assignee: Sudheer Vinukonda
Fix For: 5.2.0
In our production systems, we have proxy.config.log.log_buffer_size set to
the default value of 9216. However, we do see some very large URLs resulting
in larger log entries (about 26k bytes long). This basically results in the
warnings like the below from ATS (going into diags.log). This is good, but,
the problem is that, these WARNING messages alone fill up/flood the diags.log
pretty fast (which itself is not rotated right now). The correct solution to
this is to increase the log buffers, which we are implementing, but, it might
be nice to not flood the diags.log with the below WARNINGs as that might
result in losing/missing out on other critical/important WARNINGs. We are
thinking of implementing some sort of throttling on these kind of WARNINGs
(for e.g. 1 in every 1000 entries along with a count of how many times the
log was not displayed).
Please provide comments/suggestions.
{code}
[Oct 10 18:04:13.300] Server {0x2ad39283f700} NOTE: Skipping the current log
entry for squid.blog because its size (11000) exceeds the maximum payload
space
in a log buffer
[Oct 10 19:13:53.190] Server {0x2b1ccec45700} NOTE: Traffic Server is skipping
the current log entry because its size exceeds the maximum line (entry) size
for an ascii log buffer
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3088) Have ATS look at /etc/hosts
David Carlin created TS-3088: Summary: Have ATS look at /etc/hosts Key: TS-3088 URL: https://issues.apache.org/jira/browse/TS-3088 Project: Traffic Server Issue Type: New Feature Components: DNS Reporter: David Carlin It would be nice if /etc/hosts was read when resolving hostnames - useful for testing/troubleshooting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3088) Have ATS look at /etc/hosts
[ https://issues.apache.org/jira/browse/TS-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3088: - Assignee: Alan M. Carroll Have ATS look at /etc/hosts --- Key: TS-3088 URL: https://issues.apache.org/jira/browse/TS-3088 Project: Traffic Server Issue Type: New Feature Components: DNS Reporter: David Carlin Assignee: Alan M. Carroll It would be nice if /etc/hosts was read when resolving hostnames - useful for testing/troubleshooting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3088) Have ATS look at /etc/hosts
[ https://issues.apache.org/jira/browse/TS-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3088: - Priority: Minor (was: Major) Have ATS look at /etc/hosts --- Key: TS-3088 URL: https://issues.apache.org/jira/browse/TS-3088 Project: Traffic Server Issue Type: New Feature Components: DNS Reporter: David Carlin Assignee: Alan M. Carroll Priority: Minor It would be nice if /etc/hosts was read when resolving hostnames - useful for testing/troubleshooting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3056) traffic_logstats doesn't work on ascii logs
[ https://issues.apache.org/jira/browse/TS-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-3056: - Priority: Minor (was: Major) traffic_logstats doesn't work on ascii logs --- Key: TS-3056 URL: https://issues.apache.org/jira/browse/TS-3056 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Priority: Minor Set Mode = ascii inside LogObject in logs_xml.config - with ascii logging, traffic_logstats no longer works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3056) traffic_logstats doesn't work on ascii logs
David Carlin created TS-3056: Summary: traffic_logstats doesn't work on ascii logs Key: TS-3056 URL: https://issues.apache.org/jira/browse/TS-3056 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Set Mode = ascii inside LogObject in logs_xml.config - with ascii logging, traffic_logstats no longer works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103776#comment-14103776
]
David Carlin commented on TS-3025:
--
Is this the same as TS-1798 ?
Segmentation fault
--
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3025:
-
Summary: Segmentation fault when SPDY enabled (was: Segmentation fault)
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2925) Changing logging mode breaks log rotation
[ https://issues.apache.org/jira/browse/TS-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059800#comment-14059800 ] David Carlin commented on TS-2925: -- Actually it seems none of the squid.blog* files get rotated after switching to ascii mode. I setup a cluster of hosts and let them run in binary mode for a day. I then switched to ascii. The ascii logs are rotating, but I still have about a dozen binary logs on each host for squid.blog sitting around not being rotated. Changing logging mode breaks log rotation - Key: TS-2925 URL: https://issues.apache.org/jira/browse/TS-2925 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.0.2 Reporter: David Carlin Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: sometime If you run a server with a logging mode of binary, traffic server automatically creates logs with .blog appended. If you then switch to ascii mode, it automatically starts appending .log but leaves squid.blog on the disk indefinitely. This eats up space that would otherwise be available for logging/log rotation activity. ATS seems to rotate out all of the old binary logs except 'squid.blog'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2925) Changing logging mode breaks log rotation
[ https://issues.apache.org/jira/browse/TS-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059835#comment-14059835 ] David Carlin commented on TS-2925: -- Perhpas that explains my original comment, where I had hosts that had long been switched to ascii mode, but squid.blog remained on the host. Log space threshold was reached and it deleted all of the *.old log files, but kept squid.blog? I am assuming log space threshold doesn't remove squid.blog/squid.log only the *.old ones. This has caused some space consumption issues for us, but there is a simple workaround (delete the old binary log files). The primary annoyance is that things don't start failing until long after the change is made. Changing logging mode breaks log rotation - Key: TS-2925 URL: https://issues.apache.org/jira/browse/TS-2925 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.0.2 Reporter: David Carlin Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: sometime If you run a server with a logging mode of binary, traffic server automatically creates logs with .blog appended. If you then switch to ascii mode, it automatically starts appending .log but leaves squid.blog on the disk indefinitely. This eats up space that would otherwise be available for logging/log rotation activity. ATS seems to rotate out all of the old binary logs except 'squid.blog'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2934) Default remap rule will remap synthetic test
[ https://issues.apache.org/jira/browse/TS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14058169#comment-14058169 ] David Carlin commented on TS-2934: -- I wasn't referring to this bug; I was asked about the presence of the above entry in our remap.config... it was a holdover from YTS which required the above rule if you had a 'catchall' remap map / http://yahoo.com; in your remap.config Default remap rule will remap synthetic test Key: TS-2934 URL: https://issues.apache.org/jira/browse/TS-2934 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Fix For: 5.1.0 If you have a map / https://www.yahoo.com in remap.config the health check will match this rule and remap the health check. This shouldn't happen if there is a health check happening. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2817) ATS crash in SSLNetVConnection::load_buffer_and_write
[
https://issues.apache.org/jira/browse/TS-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001080#comment-14001080
]
David Carlin commented on TS-2817:
--
{noformat}
#0 0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
#2 0x006fbb6f in do_SSL_write (this=0x2b0fd806e780, towrite=612387,
wattempted=@0x2b0e68b09c28,
total_wrote=@0x2b0e68b09c30, buf=value optimized out,
needs=@0x2b0e68b09c38)
at SSLNetVConnection.cc:90
#3 SSLNetVConnection::load_buffer_and_write (this=0x2b0fd806e780,
towrite=612387,
wattempted=@0x2b0e68b09c28, total_wrote=@0x2b0e68b09c30, buf=value
optimized out,
needs=@0x2b0e68b09c38) at SSLNetVConnection.cc:399
#4 0x0070f938 in write_to_net_io (nh=0x2b0e6313cc10, vc=0x2b0fd806e780,
thread=value optimized out) at UnixNetVConnection.cc:527
#5 0x007046d3 in NetHandler::mainNetEvent (this=0x2b0e6313cc10,
event=value optimized out,
e=value optimized out) at UnixNet.cc:415
#6 0x0073278f in handleEvent (this=0x2b0e63139010, e=0x2067fb0,
calling_code=5)
at I_Continuation.h:146
#7 EThread::process_event (this=0x2b0e63139010, e=0x2067fb0, calling_code=5)
at UnixEThread.cc:145
#8 0x00733133 in EThread::execute (this=0x2b0e63139010) at
UnixEThread.cc:269
#9 0x00731b3a in spawn_thread_internal (a=0x233f4e0) at Thread.cc:88
#10 0x2b0e4dd5a851 in start_thread () from /lib64/libpthread.so.0
#11 0x003296ee890d in clone () from /lib64/libc.so.6
{noformat}
ATS crash in SSLNetVConnection::load_buffer_and_write
-
Key: TS-2817
URL: https://issues.apache.org/jira/browse/TS-2817
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Our production host running latest master crashed with the below stack
traces. Based on the stack traces, this might be related to a recent jira
TS-2815.
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b8c4da4f500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6fbb6f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x368)[0x70f938]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b8c4da47851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[example_alarm_bin.sh] sent alarm: l10.ycs.sjb.yahoo.com [Sat May 17 20:13:29
2014] The TS-TM connection is broken for some reason. Either restart TS and TM
or correct this error for TM
to display TS statistics correctly
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2aed4fbcc500]
/lib64/libc.so.6(memcpy+0x15b)[0x3296e8997b]
/home/y/bin/traffic_server(_ZN9LogAccess11marshal_memEPcPKcii+0x2f)[0x60f11f]
/home/y/bin/traffic_server(_ZN13LogAccessHttp28marshal_client_req_url_canonEPc+0x20)[0x6114e0]
/home/y/bin/traffic_server(_ZN12LogFieldList7marshalEP9LogAccessPc+0x32)[0x61d1e2]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPKc+0x319)[0x628ba9]
/home/y/bin/traffic_server(_ZN16LogObjectManager3logEP9LogAccess+0x5e)[0x6295be]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x5d8)[0x599ce8]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x7a0)[0x5a4a40]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x188)[0x5a4dc8]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xe0)[0x5e7050]
/home/y/bin/traffic_server[0x70d6f1]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x95b)[0x70ff2b]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x7046d3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73278f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x733133]
/home/y/bin/traffic_server[0x731b3a]
/lib64/libpthread.so.0(+0x3297207851)[0x2aed4fbc4851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log
[jira] [Commented] (TS-2461) ATS report 404 error and 301 at the same time for URL redirect
[ https://issues.apache.org/jira/browse/TS-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967088#comment-13967088 ] David Carlin commented on TS-2461: -- We are observing this as well, and it was a cause of some alarm until we realized the log messages are false and the request was processed correctly. ATS report 404 error and 301 at the same time for URL redirect -- Key: TS-2461 URL: https://issues.apache.org/jira/browse/TS-2461 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Hong Ye Fix For: 5.0.0 While trying out ATS4.0.1, I noticed ATS logs 3 messages in transaction log for each url redirect request. The request was processed correctly though. Also ATS logs two messages in error.log (same as https://issues.apache.org/jira/browse/TS-2344). Here is how to repeat: remap.config rule: redirect http://yahoo.com http://www.yahoo.com/ Output: curl -sIH HOST: yahoo.com http://68.87.98.100 HTTP/1.1 301 Redirect Date: Mon, 30 Dec 2013 20:07:45 GMT Server: ATS/4.0.1 Cache-Control: no-store Content-Type: text/html; charset=utf-8 Content-Language: en Connection: close Location: http://www.yahoo.com/ Content-Length: 214 Transaction log: tail -f cclog.log | grep 68.87.98.108 2013-12-30 20:07:45 68.87.98.108 404 FIN http://yahoo.com - 2013-12-30 20:07:45 68.87.98.108 301 FIN http://yahoo.com - 2013-12-30 20:07:45 68.87.98.108 301 FIN http://yahoo.com http://www.yahoo.com/ Error log: tail -f /var/log/trafficserver/error.log | grep 68.87.98.108 20131230.20h07m45s RESPONSE: sent 68.87.98.108 status 404 (Not Found on Accelerator) for 'http:///' 20131230.20h07m45s RESPONSE: sent 68.87.98.108 status 301 (Redirect) for 'http:///' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2461) ATS report 404 error and 301 at the same time for URL redirect
[ https://issues.apache.org/jira/browse/TS-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967088#comment-13967088 ] David Carlin edited comment on TS-2461 at 4/11/14 8:56 PM: --- We are observing this as well, and it was a cause of some alarm until we realized the log messages are false and the request was processed correctly. We are seeing this when HTTP is redirected to HTTPS was (Author: dcarlin): We are observing this as well, and it was a cause of some alarm until we realized the log messages are false and the request was processed correctly. ATS report 404 error and 301 at the same time for URL redirect -- Key: TS-2461 URL: https://issues.apache.org/jira/browse/TS-2461 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Hong Ye Fix For: 5.0.0 While trying out ATS4.0.1, I noticed ATS logs 3 messages in transaction log for each url redirect request. The request was processed correctly though. Also ATS logs two messages in error.log (same as https://issues.apache.org/jira/browse/TS-2344). Here is how to repeat: remap.config rule: redirect http://yahoo.com http://www.yahoo.com/ Output: curl -sIH HOST: yahoo.com http://68.87.98.100 HTTP/1.1 301 Redirect Date: Mon, 30 Dec 2013 20:07:45 GMT Server: ATS/4.0.1 Cache-Control: no-store Content-Type: text/html; charset=utf-8 Content-Language: en Connection: close Location: http://www.yahoo.com/ Content-Length: 214 Transaction log: tail -f cclog.log | grep 68.87.98.108 2013-12-30 20:07:45 68.87.98.108 404 FIN http://yahoo.com - 2013-12-30 20:07:45 68.87.98.108 301 FIN http://yahoo.com - 2013-12-30 20:07:45 68.87.98.108 301 FIN http://yahoo.com http://www.yahoo.com/ Error log: tail -f /var/log/trafficserver/error.log | grep 68.87.98.108 20131230.20h07m45s RESPONSE: sent 68.87.98.108 status 404 (Not Found on Accelerator) for 'http:///' 20131230.20h07m45s RESPONSE: sent 68.87.98.108 status 301 (Redirect) for 'http:///' -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13914717#comment-13914717
]
David Carlin commented on TS-2580:
--
We are using a patched version of 1.0.1e - includes these backported fixes from
1.0.1f:
https://rhn.redhat.com/errata/RHSA-2014-0015.html
SSL Connection reset by peer errors in 4.2.0-rc0
Key: TS-2580
URL: https://issues.apache.org/jira/browse/TS-2580
Project: Traffic Server
Issue Type: Bug
Components: Network, SSL
Affects Versions: 4.2.0
Reporter: David Carlin
Priority: Blocker
Fix For: 4.2.0
This error is filling /var/log/messages when using 4.2.0-rc0:
{noformat}Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer{noformat}
Did something change in the logging level and the connection resets are
normal?
Whats interesting is that this problem comes and goes as I progress through
the git bisect for TS-2564, so I may need to do another git bisect for this
issue.
TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
David Carlin created TS-2580:
Summary: SSL Connection reset by peer errors in 4.2.0-rc0
Key: TS-2580
URL: https://issues.apache.org/jira/browse/TS-2580
Project: Traffic Server
Issue Type: Bug
Components: Network, SSL
Reporter: David Carlin
This error is filling /var/log/messages when using 4.2.0-rc0:
Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer
Whats interesting is that this problem comes and goes as I progress through the
git bisect for TS-2564, so I may need to do another git bisect for this issue.
TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2580:
-
Priority: Blocker (was: Major)
SSL Connection reset by peer errors in 4.2.0-rc0
Key: TS-2580
URL: https://issues.apache.org/jira/browse/TS-2580
Project: Traffic Server
Issue Type: Bug
Components: Network, SSL
Reporter: David Carlin
Priority: Blocker
This error is filling /var/log/messages when using 4.2.0-rc0:
Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Whats interesting is that this problem comes and goes as I progress through
the git bisect for TS-2564, so I may need to do another git bisect for this
issue.
TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2580:
-
Description:
This error is filling /var/log/messages when using 4.2.0-rc0:
{noformat}Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer{noformat}
Did something change in the logging level and the connection resets are normal?
Whats interesting is that this problem comes and goes as I progress through the
git bisect for TS-2564, so I may need to do another git bisect for this issue.
TS-2548 would help me troubleshoot this via tcpdump.
was:
This error is filling /var/log/messages when using 4.2.0-rc0:
Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer
Whats interesting is that this problem comes and goes as I progress through the
git bisect for TS-2564, so I may need to do another git bisect for this issue.
TS-2548 would help me troubleshoot this via tcpdump.
SSL Connection reset by peer errors in 4.2.0-rc0
Key: TS-2580
URL: https://issues.apache.org/jira/browse/TS-2580
Project: Traffic Server
Issue Type: Bug
Components: Network, SSL
Reporter: David Carlin
Priority: Blocker
This error is filling /var/log/messages when using 4.2.0-rc0:
{noformat}Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer{noformat}
Did something change in the logging level and the connection resets are
normal?
Whats interesting is that this problem comes and goes as I progress through
the git bisect for TS-2564, so I may need to do another git bisect for this
issue.
TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2580:
-
Affects Version/s: 4.2.0
SSL Connection reset by peer errors in 4.2.0-rc0
Key: TS-2580
URL: https://issues.apache.org/jira/browse/TS-2580
Project: Traffic Server
Issue Type: Bug
Components: Network, SSL
Affects Versions: 4.2.0
Reporter: David Carlin
Priority: Blocker
Fix For: 4.2.0
This error is filling /var/log/messages when using 4.2.0-rc0:
{noformat}Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer{noformat}
Did something change in the logging level and the connection resets are
normal?
Whats interesting is that this problem comes and goes as I progress through
the git bisect for TS-2564, so I may need to do another git bisect for this
issue.
TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2580:
-
Fix Version/s: 4.2.0
SSL Connection reset by peer errors in 4.2.0-rc0
Key: TS-2580
URL: https://issues.apache.org/jira/browse/TS-2580
Project: Traffic Server
Issue Type: Bug
Components: Network, SSL
Affects Versions: 4.2.0
Reporter: David Carlin
Priority: Blocker
Fix For: 4.2.0
This error is filling /var/log/messages when using 4.2.0-rc0:
{noformat}Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer{noformat}
Did something change in the logging level and the connection resets are
normal?
Whats interesting is that this problem comes and goes as I progress through
the git bisect for TS-2564, so I may need to do another git bisect for this
issue.
TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13905063#comment-13905063
]
David Carlin commented on TS-2564:
--
The end of the git bisect determined this was the bad commit, which seems
extremely unlikely:
{noformat}84f92083cd3aa46f4095eb00463dbace1cc2708c is the first bad commit
commit 84f92083cd3aa46f4095eb00463dbace1cc2708c
Author: Bryan Call bc...@apache.org
Date: Mon Dec 16 14:59:17 2013 -0800
TS-2355: ATS 4.0.x crashes when using OpenSSL 1.0.1e
:100644 100644 aeff1664a0f3d4b328cc5e008fb25b61a3bb9135
084d8c28a537865ba6028ef37161b30e8da5caa9 M CHANGES{noformat}
I hypothesized that one of the builds in the git bisect changed/corrupted the
cache, and all subsequent builds became 'bad'. I tested this hypothesis by
going back to an earlier good commit - 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
- and it was now crashing since the cache was tainted. I went back further
still to 4.1.2 - it too now crashes. I then went all the way back to 4.0.2
which makes up the majority of our production environment, it too is now
crashing with the same stack trace.
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903229#comment-13903229
]
David Carlin commented on TS-2564:
--
afd86ed6fefc248b05dbe703685a0b7278b76442 crashed; testing
52ce5d251283178e91d2f0a535b479b797ed0934 - TS-2436: Add initial tsqa test
harness
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71
# skip: [49bb787a7d83105e9f20047a43411b0c8db2611c] Improve plugin.config
documentation
git bisect skip 49bb787a7d83105e9f20047a43411b0c8db2611c
# bad: [afd86ed6fefc248b05dbe703685a0b7278b76442] build fixes
git bisect bad afd86ed6fefc248b05dbe703685a0b7278b76442{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903229#comment-13903229
]
David Carlin edited comment on TS-2564 at 2/17/14 1:35 PM:
---
afd86ed6fefc248b05dbe703685a0b7278b76442 crashed; testing:
{noformat}commit 52ce5d251283178e91d2f0a535b479b797ed0934
Author: James Peach jpe...@apache.org
Date: Fri Dec 13 17:09:51 2013 -0800
TS-2436: Add initial tsqa test harness{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71
# skip: [49bb787a7d83105e9f20047a43411b0c8db2611c] Improve plugin.config
documentation
git bisect skip 49bb787a7d83105e9f20047a43411b0c8db2611c
# bad: [afd86ed6fefc248b05dbe703685a0b7278b76442] build fixes
git bisect bad afd86ed6fefc248b05dbe703685a0b7278b76442{noformat}
was (Author: dcarlin):
afd86ed6fefc248b05dbe703685a0b7278b76442 crashed; testing
52ce5d251283178e91d2f0a535b479b797ed0934 - TS-2436: Add initial tsqa test
harness
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71
# skip: [49bb787a7d83105e9f20047a43411b0c8db2611c] Improve plugin.config
documentation
git bisect skip 49bb787a7d83105e9f20047a43411b0c8db2611c
# bad: [afd86ed6fefc248b05dbe703685a0b7278b76442] build fixes
git bisect bad afd86ed6fefc248b05dbe703685a0b7278b76442{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903315#comment-13903315
]
David Carlin commented on TS-2564:
--
52ce5d251283178e91d2f0a535b479b797ed0934 crashed. Testing:
{noformat}commit 46b845d7c778aa99855c937190ee7acf8cfd
Author: James Peach jpe...@apache.org
Date: Fri Dec 13 17:09:05 2013 -0800
TS-2436: add more tsxs query variables{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71
# skip: [49bb787a7d83105e9f20047a43411b0c8db2611c] Improve plugin.config
documentation
git bisect skip 49bb787a7d83105e9f20047a43411b0c8db2611c
# bad: [afd86ed6fefc248b05dbe703685a0b7278b76442] build fixes
git bisect bad afd86ed6fefc248b05dbe703685a0b7278b76442
# bad: [52ce5d251283178e91d2f0a535b479b797ed0934] TS-2436: Add initial tsqa
test harness
git bisect bad 52ce5d251283178e91d2f0a535b479b797ed0934{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903730#comment-13903730
]
David Carlin commented on TS-2564:
--
46b845d7c778aa99855c937190ee7acf8cfd crashed; testing:
{noformat}commit 84f92083cd3aa46f4095eb00463dbace1cc2708c
Author: Bryan Call bc...@apache.org
Date: Mon Dec 16 14:59:17 2013 -0800
TS-2355: ATS 4.0.x crashes when using OpenSSL 1.0.1e{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71
# skip: [49bb787a7d83105e9f20047a43411b0c8db2611c] Improve plugin.config
documentation
git bisect skip 49bb787a7d83105e9f20047a43411b0c8db2611c
# bad: [afd86ed6fefc248b05dbe703685a0b7278b76442] build fixes
git bisect bad afd86ed6fefc248b05dbe703685a0b7278b76442
# bad: [52ce5d251283178e91d2f0a535b479b797ed0934] TS-2436: Add initial tsqa
test harness
git bisect bad 52ce5d251283178e91d2f0a535b479b797ed0934
# bad: [46b845d7c778aa99855c937190ee7acf8cfd] TS-2436: add more tsxs query
variables
git bisect bad 46b845d7c778aa99855c937190ee7acf8cfd{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902704#comment-13902704
]
David Carlin commented on TS-2564:
--
05f7bfb57517e60a364a62dd171e5cc65824aa4a crashed. Testing this build:
{noformat}commit 90af89c47425cf55ca1a472ec68847afb2efc57a
Merge: 9e06528 0c953e1
Author: Miles Libbey mlib...@apache.org
Date: Wed Dec 18 17:03:02 2013 -0800
Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver{noformat}
{noformat}
git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902822#comment-13902822
]
David Carlin commented on TS-2564:
--
90af89c47425cf55ca1a472ec68847afb2efc57a crashed - now testing:
{noformat}commit 0c953e129225ed6db59a97d293d26ecae3f22c92
Author: Alan M. Carroll a...@network-geographics.com
Date: Wed Dec 18 14:55:20 2013 -0600
Doc: Clean up in cache architecture, added information about stripe
assignment initialization.{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902846#comment-13902846
]
David Carlin commented on TS-2564:
--
0c953e129225ed6db59a97d293d26ecae3f22c92 crashed - now testing:
{noformat}commit 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
Author: James Peach jpe...@apache.org
Date: Mon Dec 16 09:33:39 2013 -0800
TS-2434: use FATAL error level to handle plugin errors{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902846#comment-13902846
]
David Carlin edited comment on TS-2564 at 2/16/14 9:43 PM:
---
0c953e129225ed6db59a97d293d26ecae3f22c92 crashed. I couldn't build
6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf which was next build for testing in
git bisect - skipped it and built/testing
fb46319d2a3b43c6362d24093f458074f7047c71 instead.
{noformat}commit fb46319d2a3b43c6362d24093f458074f7047c71
Author: David Biehl m...@davidbiehl.com
Date: Tue Dec 17 10:04:46 2013 -0800
Corrects a spelling error
tuicket = ticket{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf{noformat}
was (Author: dcarlin):
0c953e129225ed6db59a97d293d26ecae3f22c92 crashed - now testing:
{noformat}commit 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
Author: James Peach jpe...@apache.org
Date: Mon Dec 16 09:33:39 2013 -0800
TS-2434: use FATAL error level to handle plugin errors{noformat}
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5
[jira] [Comment Edited] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902963#comment-13902963
]
David Carlin edited comment on TS-2564 at 2/17/14 5:14 AM:
---
fb46319d2a3b43c6362d24093f458074f7047c71 has the same crash; testing
49bb787a7d83105e9f20047a43411b0c8db2611c
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71{noformat}
was (Author: dcarlin):
fb46319d2a3b43c6362d24093f458074f7047c71 has the same crash; testing
49bb787a7d83105e9f20047a43411b0c8db2611c
{noformat}git bisect log
git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902963#comment-13902963
]
David Carlin commented on TS-2564:
--
fb46319d2a3b43c6362d24093f458074f7047c71 has the same crash; testing
49bb787a7d83105e9f20047a43411b0c8db2611c
{noformat}git bisect log
git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902963#comment-13902963
]
David Carlin edited comment on TS-2564 at 2/17/14 5:29 AM:
---
fb46319d2a3b43c6362d24093f458074f7047c71 has the same crash; next bisect would
have been 49bb787a7d83105e9f20047a43411b0c8db2611c but I couldn't build it;
testing afd86ed6fefc248b05dbe703685a0b7278b76442 instead.
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71
# skip: [49bb787a7d83105e9f20047a43411b0c8db2611c] Improve plugin.config
documentation
git bisect skip 49bb787a7d83105e9f20047a43411b0c8db2611c{noformat}
was (Author: dcarlin):
fb46319d2a3b43c6362d24093f458074f7047c71 has the same crash; testing
49bb787a7d83105e9f20047a43411b0c8db2611c
{noformat}git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
# bad: [05f7bfb57517e60a364a62dd171e5cc65824aa4a] TS-32: minimum FIX to let ICP
work
git bisect bad 05f7bfb57517e60a364a62dd171e5cc65824aa4a
# bad: [90af89c47425cf55ca1a472ec68847afb2efc57a] Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
git bisect bad 90af89c47425cf55ca1a472ec68847afb2efc57a
# bad: [0c953e129225ed6db59a97d293d26ecae3f22c92] Doc: Clean up in cache
architecture, added information about stripe assignment initialization.
git bisect bad 0c953e129225ed6db59a97d293d26ecae3f22c92
# skip: [6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf] TS-2434: use FATAL error
level to handle plugin errors
git bisect skip 6ce376a8f2f027d329f4b1a1f79d75c1ed4a7dcf
# bad: [fb46319d2a3b43c6362d24093f458074f7047c71] Corrects a spelling error
git bisect bad fb46319d2a3b43c6362d24093f458074f7047c71{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902485#comment-13902485
]
David Carlin commented on TS-2564:
--
I marked the above two builds as good. Now running the following two builds:
{noformat}941c358c8791fae7a030c0ff26b52f26f4db456c - Fix typo
f8cb33617947d6ca27208a57cff7758fc7529391 - TS-2505 Add --offline to
traffic_line{noformat}
{noformat}$ git bisect log
git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# good: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect good 941c358c8791fae7a030c0ff26b52f26f4db456c{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13902611#comment-13902611
]
David Carlin commented on TS-2564:
--
941c358c8791fae7a030c0ff26b52f26f4db456c crashed. Now testing this build:
commit 05f7bfb57517e60a364a62dd171e5cc65824aa4a
Author: Gota Adachi a...@iij.ad.jp
Date: Tue Dec 24 15:15:38 2013 +0800
TS-32: minimum FIX to let ICP work
{noformat}
git bisect start
# good: [de710cb9b33375abbb4dfae5ac078bc8daefb540] reliably recreate the same
tar-ball from the same content
git bisect good de710cb9b33375abbb4dfae5ac078bc8daefb540
# bad: [f0f9cb9c3521873df900ece090b890d789d50594] Update CHANGES for TS-2550
git bisect bad f0f9cb9c3521873df900ece090b890d789d50594
# good: [2b0351f43d64a2fd69c7f95d81df4a163826999d] jenkins config: Prepare for
4.1.x release cycle
git bisect good 2b0351f43d64a2fd69c7f95d81df4a163826999d
# good: [2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e] TS-2355: ATS 4.0.x crashes
when using OpenSSL 1.0.1e
git bisect good 2a979548dbf17dea5fbeb43e79116b4c3dcf4a6e
# bad: [941c358c8791fae7a030c0ff26b52f26f4db456c] Fix typo
git bisect bad 941c358c8791fae7a030c0ff26b52f26f4db456c
{noformat}
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin reassigned TS-2564:
Assignee: David Carlin
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: David Carlin
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-2564:
-
Assignee: Bryan Call (was: David Carlin)
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2548) Add client IP to SSLError() calls in SSLNetVConnection
David Carlin created TS-2548: Summary: Add client IP to SSLError() calls in SSLNetVConnection Key: TS-2548 URL: https://issues.apache.org/jira/browse/TS-2548 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: David Carlin I asked on IRC if we could put the Client IP in the SSL errors that appear in diags.log and /var/log/messages - jpeach replied that it was a matter of adding client IP to SSLError() calls in SSLNetVConnection. This would be very helpful for troubleshooting. Additionally, why are the errors sent to /var/log/messages - writing them to only diags.log is preferable. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2524) Reevaluate default proxy.config.net.listen_backlog
David Carlin created TS-2524: Summary: Reevaluate default proxy.config.net.listen_backlog Key: TS-2524 URL: https://issues.apache.org/jira/browse/TS-2524 Project: Traffic Server Issue Type: Bug Components: Network Reporter: David Carlin Leif mentioned in TS-2395 that he was having some problems related to proxy.config.net.listen_backlog. According to this article: http://blog.dubbelboer.com/2012/04/09/syn-cookies.html the kernel takes the backlog value, adds 1 and rounds up to the nearest power of 2. It sets max queue length to the log2 value of this number. This is why backlog of 511 results in max queue length of 9 (what you want) where as setting backlog to 512 expecting a max queue length of 9 you end up with 10. The above article mentions that nginx and apache set a default backlog of 511. We have a systemtap script that shows current queue length and max queue length, I never see a max queue length greater than 15 (32768 connections) even when I set proxy.config.net.listen_backlog to 2^16 or 2^16 -1 so not sure why 2^16-1 made a difference for you. Isn't this value in records config of type INT (signed) so it can't be more than 2^15 anyways? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
