[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&focusedCommentId=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] [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] [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: - 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:
-
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 sta
[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 as the messages are not grouped together/written sequentially.
{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 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 br
[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] [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&focusedCommentId=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
> (this=0x2b4a5ca1c5c0)
[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
> (niv=2)
> [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
> [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
> [ 0.163] send HEADERS frame
> ; END_STREAM | END_HEADERS
> (padlen=0)
> ; Open new stream
> :method: GET
> :path: /os/bossnext/0.1.187/js/40.69bc98cf2f62459d4ce9.min.js
> :scheme: https
> :authority: s.yimg.com
> accept: */*
> accept-encoding: gzip, deflate
> user-agent: nghttp2/0.7.11-DEV
> [ 0.163] recv SETTINGS frame
> (niv=1)
> [SETTINGS_INITIAL_WINDOW_SIZE(0x04):1048576]
> [ 0.163] send SETTINGS frame
> ; ACK
> (niv=0)
> [ 0.163] recv WINDOW_UPDATE frame
> (window_size_increment=983041)
> [ 0.213] recv SETTINGS frame
> ; ACK
> (niv=0)
> [ 0.264] recv (stream_id=1, sensitive) :status: 200
> [ 0.264] recv (stream_id=1) accept-ranges: bytes
> [ 0.264] recv (stream_id=1) cache-control: max-age=536112000
> [ 0.264] recv (stream_id=1) content-encoding: gzip
> [ 0.264] recv (stream_id=1) content-type: application/javascript
> [ 0.264] recv (stream_id=1) date: Tue, 29 Sep 2015 22:16:54 GMT
> [ 0.264] recv (stream_id=1) etag:
> "YM:1:bcf1abbc-31fc-42f2-aa31-37f6848c126700052082483e3025"
> [ 0.264] recv (stream_id=1) expires: Fri, 24 Sep 2032 22:16:54 GMT
> [ 0.264] recv (stream_id=1) last-modified: Thu, 24 Sep 2015 18:20:13 GMT
> [ 0.264] recv (stream_id=1) server: ATS
> [ 0.264] recv (stream_id=1) vary: Accept-Encoding
> [ 0.264] recv (stream_id=1) via: HTTP/1.1 web4.usw45.mobstor.gq1.yahoo.com
> UserFiberFramework/1.0, https/1.1 l7.ycs.swp.yahoo.com (ApacheTrafficServer
> [cMsSfW])
> [ 0.264] recv (stream_id=1) x-ysws-request-id:
> f67de7a0-ab76-4437-b73f-6c461a808f13
> [ 0.264] recv (stream_id=1) x-ysws-visited-replicas:
> gops.usw45.mobstor.vip.gq1.yahoo.com
> [ 0.264] recv (stream_id=1) age: 0
> [ 0.264] recv HEADERS frame
> ; END_HEADERS
> (padlen=0)
> ; First response header
> webpackJsonp([40],{565:function(e,t,n){"use
> strict";e.exports={controllerViews:{compAnswersContainer_WDC:n(604),compYahooAnswersContainer_WDC:n(605)},actions:{},stores:{}}},604:function(e,t,n){"use
> strict";var
> r,s=n(1),i=n(2),a=n(5),o=n(11),l=n(13),c=n(37),u=n(12);r=s.createClass({displayName:"CompAnswers",mixins:[i,u],shouldComponentUpdate:function(e,t){return!1},getProfileImgDimensions:function(e){return{width:24,height:24}},getColonSeparatedKeyValuePair:function(e){var
> t=e.split(":"),n=t[0],r=t[1];return{key:n,value:r}},render:function(){var
> e,t,n=this,r=this.context.getStore(a),i=r.getPageConfig(),u=[];return
> this.props&&this.props.config&&(t=this.props.config.items),t&&t.constructor===Array&&0!==t.length?(u=t.reduce(function(e,t,r){var
>
> i="AnswersIntl"+r,a={data:t.data,meta:t.meta&&t.meta.conf||{}};switch(t.type){case"compTitle":if(a.data&&a.data.constructor===Array&&a.data[0].text&&a.data[0].text.txt){var
>
> u=n.getColonSeparatedKeyValuePair(a.data[0].text.txt);"search.sc.sccs.answers.answers_dd.title"===u.key&&(a.data[0].text.txt=u.value+"
> -
> "+n.getIntlMessage("YAHOO_ANSWERS_RESULTS"))}e.push(s.createElement(o,{key:i,config:a,infoCls:"Txt
> C(#5f5f5f)! M(0px) Fw(400) D(ib)",divCls:"C(#5f5f5f)! Mt(10px)
> Fz(1.5rem)"}));break;case"compArticleList":e.push(s.createElement(c,{key:i,config:a,fnGetSubImageDimensions:n.getProfileImgDimensions,subImageWrapWidth:24,subImageWrapCls:"Fl(start)
> Pos(r) Bgc(#000)",linkCls:"",infoCls:"Fz(1.3rem) Fw(n)
> M(0px)",subTxtCls:"Mb(4px) Mt(0px) Pstart(12px)
> LineClamp(2)",listItemCls:"Ov(a) D(b)
> Mt(10px)",listCls:"M(0px)",contentCls:"Ov(h) Pstart(12px)
> Pos(r)",subTextTxtCls:"Pstart(12px) Ov(h)
> LineClamp(3)",subTextCiteCls:"C(#1e7d8e)
[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-3860) Buffer overflow in H2 on debug build
[
https://issues.apache.org/jira/browse/TS-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3860:
-
Labels: yahoo (was: )
> Buffer overflow in H2 on debug build
>
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Leif Hedstrom
> Labels: yahoo
> Fix For: 6.1.0
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int)
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*)
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int,
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*,
> unsigned long, Http2DynamicTable&)
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*)
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*)
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*)
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*)
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*)
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*)
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int)
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute()
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7'
> from 'HPACK.cc' (0xacafe0) of size 8
> '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char
> const*, int)
> Shadow bytes around the buggy address:
> 0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> 0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
> 0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
> 0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
> 0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
> 0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
> 0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
> 0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
> 0x80151630: 00 00 00 05 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> 0x80151640: 00 00 03 f9 f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Heap right redzone: fb
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack partial redzone: f4
> Sta
[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-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] [Created] (TS-3809) Corrupt debug log messages LogFormat::parse_format_string
David Carlin created TS-3809:
Summary: 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
Reporter: David Carlin
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-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:
-
Affects Version/s: 5.3.0
> 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-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}
>
>
>% % % % % % %
> % %/% % % f1 f2 f3 f4"/>
>
>
>
>
>
>
> {noformat}
--
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 {
[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-tabpanel&focusedCommentId=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
[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 Ptr::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:
-
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 Ptr::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: - 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] [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] [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:
>
[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-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-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-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=1&o=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(c
[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=14561404&page=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=14561404&page=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=14561404&page=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: - 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=14561404&page=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] [Created] (TS-3643) TS-2944 changes logging format / breaks compatibility
David Carlin created TS-3643: Summary: 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 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=14561404&page=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-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-tabpanel&focusedCommentId=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] [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] [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] [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] [Commented] (TS-3534) Wiretracing for SSL connections
[ https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (TS-3534) Wiretracing for SSL connections
[ https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3534) Wiretracing for SSL connections
[ https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-153) "Dynamic" keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-3243) Warnings from loading legitimate TLS certificates
[
https://issues.apache.org/jira/browse/TS-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] [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] [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] [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 in logs_xml.config - with ascii logging, traffic_logstats no longer works. -- 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 in logs_xml.config - with ascii > logging, traffic_logstats no longer works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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= optimized out>, cont=0x2aab21bed4e0,
> target=, opt=0x2b920706d940) at
> UnixNetProcessor.cc:247
> #2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:85
> #3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw= 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=,
> nh=0x2b920646cbc0, vc=0x2aab20a63310)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #8 read_signal_and_update (event=, nh=0x2b920646cbc0,
> vc=0x2aab20a63310) at UnixNetVConnection.cc:137
> #9 read_signal_done (event=, nh=0x2b920646cbc0,
> vc=0x2aab20a63310) at UnixNetVConnection.cc:167
> #10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
> vc=0x2aab20a63310, thread=) at UnixNetVConnection.cc:291
> #11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
> event=, e=)
> 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-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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= optimized out>, cont=0x2aab21bed4e0,
> target=, opt=0x2b920706d940) at
> UnixNetProcessor.cc:247
> #2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw= optimized out>) at ../../iocore/net/P_UnixNetProcessor.h:85
> #3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw= 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=,
> nh=0x2b920646cbc0, vc=0x2aab20a63310)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #8 read_signal_and_update (event=, nh=0x2b920646cbc0,
> vc=0x2aab20a63310) at UnixNetVConnection.cc:137
> #9 read_signal_done (event=, nh=0x2b920646cbc0,
> vc=0x2aab20a63310) at UnixNetVConnection.cc:167
> #10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
> vc=0x2aab20a63310, thread=) at UnixNetVConnection.cc:291
> #11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
> event=, e=)
> 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-tabpanel&focusedCommentId=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-2925) Changing logging mode breaks log rotation
[ https://issues.apache.org/jira/browse/TS-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2934) Default remap rule will remap synthetic test
[ https://issues.apache.org/jira/browse/TS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (TS-2925) Changing logging mode breaks log rotation
[ https://issues.apache.org/jira/browse/TS-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-2925: - Labels: yahoo (was: ) > 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 >Priority: Minor > Labels: yahoo > > 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] [Created] (TS-2925) Changing logging mode breaks log rotation
David Carlin created TS-2925: Summary: 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 Reporter: David Carlin 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] [Updated] (TS-2925) Changing logging mode breaks log rotation
[ https://issues.apache.org/jira/browse/TS-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-2925: - Priority: Minor (was: Major) > 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 >Priority: Minor > Labels: yahoo > > 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] [Updated] (TS-2925) Changing logging mode breaks log rotation
[ https://issues.apache.org/jira/browse/TS-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-2925: - Affects Version/s: 4.0.2 > 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 >Priority: Minor > Labels: yahoo > > 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-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-tabpanel&focusedCommentId=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=,
needs=@0x2b0e68b09c38)
at SSLNetVConnection.cc:90
#3 SSLNetVConnection::load_buffer_and_write (this=0x2b0fd806e780,
towrite=612387,
wattempted=@0x2b0e68b09c28, total_wrote=@0x2b0e68b09c30, buf=,
needs=@0x2b0e68b09c38) at SSLNetVConnection.cc:399
#4 0x0070f938 in write_to_net_io (nh=0x2b0e6313cc10, vc=0x2b0fd806e780,
thread=) at UnixNetVConnection.cc:527
#5 0x007046d3 in NetHandler::mainNetEvent (this=0x2b0e6313cc10,
event=,
e=) 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 ==> [TrafficManager] using root dire
[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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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] [Updated] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Carlin updated TS-2633: - Affects Version/s: 4.0.2 > 406 negative responses being cached for too long > > > Key: TS-2633 > URL: https://issues.apache.org/jira/browse/TS-2633 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 4.0.2 >Reporter: David Carlin > > Settings: > proxy.config.http.negative_caching_enabled = 1 > proxy.config.http.negative_caching_lifetime = 500 > 406 response is being cached, but lifetime isn't being adhered to. They are > cached for much longer, perhaps indefinitely. I have seen Age: increase to > several hours. > With proxy.config.http.negative_caching_enabled = 0 then 406 responses are > not cached. > Bryan pointed out that the docs don't list 406 as one of the cached negative > responses: > http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html > The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on > this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2633) 406 negative responses being cached for too long
David Carlin created TS-2633: Summary: 406 negative responses being cached for too long Key: TS-2633 URL: https://issues.apache.org/jira/browse/TS-2633 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: David Carlin Settings: proxy.config.http.negative_caching_enabled = 1 proxy.config.http.negative_caching_lifetime = 500 406 response is being cached, but lifetime isn't being adhered to. They are cached for much longer, perhaps indefinitely. I have seen Age: increase to several hours. With proxy.config.http.negative_caching_enabled = 0 then 406 responses are not cached. Bryan pointed out that the docs don't list 406 as one of the cached negative responses: http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on this issue. -- 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-tabpanel&focusedCommentId=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] [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] [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:
-
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] [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] [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-tabpanel&focusedCommentId=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
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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= 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-tabpanel&focusedCommentId=13903730#comment-13903730
]
David Carlin commented on TS-2564:
--
46b845d7c778aa99855c937190ee7acf8cfd crashed; testing:
{noformat}commit 84f92083cd3aa46f4095eb00463dbace1cc2708c
Author: Bryan Call
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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= 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-tabpanel&focusedCommentId=13903315#comment-13903315
]
David Carlin commented on TS-2564:
--
52ce5d251283178e91d2f0a535b479b797ed0934 crashed. Testing:
{noformat}commit 46b845d7c778aa99855c937190ee7acf8cfd
Author: James Peach
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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= 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-tabpanel&focusedCommentId=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
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=,
[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-tabpanel&focusedCommentId=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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= 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-tabpanel&focusedCommentId=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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= out>) at MIME.cc:1586
> #3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:110
[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-tabpanel&focusedCommentId=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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= 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)
