[jira] [Updated] (TS-2238) Log transfer time from start of request to last ACK has been received
[ https://issues.apache.org/jira/browse/TS-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2238: - Fix Version/s: (was: 5.0.0) > Log transfer time from start of request to last ACK has been received > - > > Key: TS-2238 > URL: https://issues.apache.org/jira/browse/TS-2238 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Ask Bjørn Hansen >Priority: Minor > > The ttms log variable logs until the last byte has been written to the > socket. For some applications it'd be useful to track the download time until > the last ACK has been received (or has timed out). It's possible that the > tcp_info data structure would have this information. > The (obvious) disadvantage is that connection might have to linger for a long > time before it can be finished and logged. Not sure if there's a reasonable > work-around for that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2238) Log transfer time from start of request to last ACK has been received
[ https://issues.apache.org/jira/browse/TS-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2238: - Fix Version/s: 5.0.0 > Log transfer time from start of request to last ACK has been received > - > > Key: TS-2238 > URL: https://issues.apache.org/jira/browse/TS-2238 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Ask Bjørn Hansen >Priority: Minor > Fix For: 5.0.0 > > > The ttms log variable logs until the last byte has been written to the > socket. For some applications it'd be useful to track the download time until > the last ACK has been received (or has timed out). It's possible that the > tcp_info data structure would have this information. > The (obvious) disadvantage is that connection might have to linger for a long > time before it can be finished and logged. Not sure if there's a reasonable > work-around for that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2240) traffic_line -x reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2240: - Fix Version/s: (was: 5.0.0) > traffic_line -x reload doesn't return result > > > Key: TS-2240 > URL: https://issues.apache.org/jira/browse/TS-2240 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Ask Bjørn Hansen > > It'd be nice if there was a variation of traffic_line -x that waits for the > result of the reload and returns an appropriate exit code (and error > information if applicable). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2240) traffic_line -x reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2240: - Fix Version/s: 5.0.0 > traffic_line -x reload doesn't return result > > > Key: TS-2240 > URL: https://issues.apache.org/jira/browse/TS-2240 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Ask Bjørn Hansen > Fix For: 5.0.0 > > > It'd be nice if there was a variation of traffic_line -x that waits for the > result of the reload and returns an appropriate exit code (and error > information if applicable). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2170) stats.config.xml is undocumented
[
https://issues.apache.org/jira/browse/TS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell updated TS-2170:
-
Fix Version/s: 5.0.0
> stats.config.xml is undocumented
>
>
> Key: TS-2170
> URL: https://issues.apache.org/jira/browse/TS-2170
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
> Fix For: 5.0.0
>
>
> Save for its DTD: {proxy/config/stats.config.dtd}, {stats.config.xml} is
> undocumented.
> We should change that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2171) cluster.config is undocumented
[
https://issues.apache.org/jira/browse/TS-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell updated TS-2171:
-
Fix Version/s: (was: 5.0.0)
> cluster.config is undocumented
> --
>
> Key: TS-2171
> URL: https://issues.apache.org/jira/browse/TS-2171
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
>
> Ignoring its default configuration file in our tree, {cluster.config} is
> undocumented.
> We should change this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2170) stats.config.xml is undocumented
[
https://issues.apache.org/jira/browse/TS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell updated TS-2170:
-
Fix Version/s: (was: 5.0.0)
> stats.config.xml is undocumented
>
>
> Key: TS-2170
> URL: https://issues.apache.org/jira/browse/TS-2170
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
>
> Save for its DTD: {proxy/config/stats.config.dtd}, {stats.config.xml} is
> undocumented.
> We should change that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2204) ts should not cache the response with unrecognized codes
[ https://issues.apache.org/jira/browse/TS-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2204: - Fix Version/s: (was: 5.0.0) > ts should not cache the response with unrecognized codes > > > Key: TS-2204 > URL: https://issues.apache.org/jira/browse/TS-2204 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP >Reporter: Zhao Yongming > > according to RFC 2616: 6.1.1 >HTTP status codes are extensible. HTTP applications are not required >to understand the meaning of all registered status codes, though such >understanding is obviously desirable. However, applications MUST >understand the class of any status code, as indicated by the first >digit, and treat any unrecognized response as being equivalent to the >x00 status code of that class, with the exception that an >unrecognized response MUST NOT be cached. For example, if an >unrecognized status code of 431 is received by the client, it can >safely assume that there was something wrong with its request and >treat the response as if it had received a 400 status code. In such >cases, user agents SHOULD present to the user the entity returned >with the response, since that entity is likely to include human- >readable information which will explain the unusual status. > and we should not cache any of the unknown response. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2213) Body log tags have a default value of "0", should they be "-1" now?
[ https://issues.apache.org/jira/browse/TS-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2213: - Fix Version/s: (was: 5.0.0) > Body log tags have a default value of "0", should they be "-1" now? > --- > > Key: TS-2213 > URL: https://issues.apache.org/jira/browse/TS-2213 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Leif Hedstrom > > In our logging tags that provides a value for the body length, we default to > 0 in the absence of a value. This is somewhat bad now, because we actually > supports caching objects with a zero length body. Hence, it's not > distinguishable between a zero length body entry, or one where we couldn't > retrieve a body length (for whatever reason). > I'm wondering if we should change all the defaults for all "byte counts" in > logging from "0" to "-1"? This would be an incompatible change, so marking > this for v5.0.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2213) Body log tags have a default value of "0", should they be "-1" now?
[ https://issues.apache.org/jira/browse/TS-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2213: - Fix Version/s: 5.0.0 > Body log tags have a default value of "0", should they be "-1" now? > --- > > Key: TS-2213 > URL: https://issues.apache.org/jira/browse/TS-2213 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Leif Hedstrom > Fix For: 5.0.0 > > > In our logging tags that provides a value for the body length, we default to > 0 in the absence of a value. This is somewhat bad now, because we actually > supports caching objects with a zero length body. Hence, it's not > distinguishable between a zero length body entry, or one where we couldn't > retrieve a body length (for whatever reason). > I'm wondering if we should change all the defaults for all "byte counts" in > logging from "0" to "-1"? This would be an incompatible change, so marking > this for v5.0.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2204) ts should not cache the response with unrecognized codes
[ https://issues.apache.org/jira/browse/TS-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2204: - Fix Version/s: 5.0.0 > ts should not cache the response with unrecognized codes > > > Key: TS-2204 > URL: https://issues.apache.org/jira/browse/TS-2204 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP >Reporter: Zhao Yongming > Fix For: 5.0.0 > > > according to RFC 2616: 6.1.1 >HTTP status codes are extensible. HTTP applications are not required >to understand the meaning of all registered status codes, though such >understanding is obviously desirable. However, applications MUST >understand the class of any status code, as indicated by the first >digit, and treat any unrecognized response as being equivalent to the >x00 status code of that class, with the exception that an >unrecognized response MUST NOT be cached. For example, if an >unrecognized status code of 431 is received by the client, it can >safely assume that there was something wrong with its request and >treat the response as if it had received a 400 status code. In such >cases, user agents SHOULD present to the user the entity returned >with the response, since that entity is likely to include human- >readable information which will explain the unusual status. > and we should not cache any of the unknown response. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2171) cluster.config is undocumented
[
https://issues.apache.org/jira/browse/TS-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell updated TS-2171:
-
Fix Version/s: 5.0.0
> cluster.config is undocumented
> --
>
> Key: TS-2171
> URL: https://issues.apache.org/jira/browse/TS-2171
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
> Fix For: 5.0.0
>
>
> Ignoring its default configuration file in our tree, {cluster.config} is
> undocumented.
> We should change this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2194) alternate renderers for HTTP UI
[ https://issues.apache.org/jira/browse/TS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2194: - Fix Version/s: (was: 5.0.0) > alternate renderers for HTTP UI > --- > > Key: TS-2194 > URL: https://issues.apache.org/jira/browse/TS-2194 > Project: Traffic Server > Issue Type: New Feature > Components: Web UI >Reporter: James Peach >Assignee: James Peach > > While reviewing TS-2191, I realized that TS gathers a lot of useful debugging > information that is only published in the Web UI pages. We should make more > of this information available to command line tools (eg. via traffic_line or > SIGINFO, etc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2194) alternate renderers for HTTP UI
[ https://issues.apache.org/jira/browse/TS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2194: - Fix Version/s: 5.0.0 > alternate renderers for HTTP UI > --- > > Key: TS-2194 > URL: https://issues.apache.org/jira/browse/TS-2194 > Project: Traffic Server > Issue Type: New Feature > Components: Web UI >Reporter: James Peach >Assignee: James Peach > Fix For: 5.0.0 > > > While reviewing TS-2191, I realized that TS gathers a lot of useful debugging > information that is only published in the Web UI pages. We should make more > of this information available to command line tools (eg. via traffic_line or > SIGINFO, etc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2225) Add line/record id to traffic_logcat
[ https://issues.apache.org/jira/browse/TS-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2225: - Fix Version/s: 5.0.0 > Add line/record id to traffic_logcat > > > Key: TS-2225 > URL: https://issues.apache.org/jira/browse/TS-2225 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Ask Bjørn Hansen > Fix For: 5.0.0 > > > For tailing the binary log it'll be useful with a concept roughly equivalent > to line number in a text file. > traffic_logcat will optionally output this and then have a feature to say > "start following from line/record X". > The record id a numeric increment for the particular log file or the request > ID (if/when that's available). > The immediate objective is for log readers to continue reading from where > they last read if they're restarted. >  -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
[ https://issues.apache.org/jira/browse/TS-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2231: - Fix Version/s: 5.0.0 > header_rewrite uses boost regexes, we should switch to PCRE > --- > > Key: TS-2231 > URL: https://issues.apache.org/jira/browse/TS-2231 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom > Fix For: 5.0.0 > > > It makes no sense to have another regex format, lets unify everything on > PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
[ https://issues.apache.org/jira/browse/TS-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2231: - Fix Version/s: (was: 5.0.0) > header_rewrite uses boost regexes, we should switch to PCRE > --- > > Key: TS-2231 > URL: https://issues.apache.org/jira/browse/TS-2231 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom > > It makes no sense to have another regex format, lets unify everything on > PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2225) Add line/record id to traffic_logcat
[ https://issues.apache.org/jira/browse/TS-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell updated TS-2225: - Fix Version/s: (was: 5.0.0) > Add line/record id to traffic_logcat > > > Key: TS-2225 > URL: https://issues.apache.org/jira/browse/TS-2225 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Ask Bjørn Hansen > > For tailing the binary log it'll be useful with a concept roughly equivalent > to line number in a text file. > traffic_logcat will optionally output this and then have a feature to say > "start following from line/record X". > The record id a numeric increment for the particular log file or the request > ID (if/when that's available). > The immediate objective is for log readers to continue reading from where > they last read if they're restarted. >  -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
